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FOREWORD 


1 .  This  standard  defines  the  Government’s  requirements  and  expectations  for  contractor 
performance  in  defense  system  acquisitions  and  technology  developments. 

2.  This  revised  SMC  standard  comprises  the  text  of  The  Aerospace  Corporation  report  number 
fOR-2010(8591)-3,  Volume  2,  entitled  Human  Computer  Interface  (HCI)  Design  Criteria 

V olume  1:  Display  Conventions  for  Space  System  Operations  which  contains  the  following  major 
changes  from  HM-RB-2001-1: 

•  Deleted  FOREWORD  describing  the  obsolete  Human  Machine  Interface  Review  Board 

•  Updated  reference  documents 

3.  Beneficial  comments  (recommendations,  changes,  additions,  deletions,  etc.)  and  any 
pertinent  data  that  may  be  of  use  in  improving  this  standard  should  be  forwarded  to  the  following 
addressee  using  the  Standardization  Document  Improvement  Proposal  appearing  at  the  end  of  this 
document  or  by  letter: 


Division  Chief,  SMC/EAE 
SPACE  AND  MISSILE  SYSTEMS  CENTER 
Air  Force  Space  Command 
483  N.  Aviation  Blvd. 

El  Segundo,  CA  90245 

4.  This  standard  has  been  approved  for  use  on  all  Space  and  Missile  Systems 
Center/Air  Force  Program  Executive  Office  -  Space  development,  acquisition,  and 
sustainment  contracts. 


DAVID  E.  SWANSON,  COL,  USAF 
SMC  Chief  Engineer 
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1 .  Overview 


The  Human  Machine  Interface  (HMI)  Conventions  Document  has  been  developed  under  the  direction 
of  and  with  oversight  from  the  United  States  (US)  Air  Force  Space  Command  (AFSPC).  It  provides 
recommended  HMI  conventions  for  use  in  designing  satellite  operations  systems.  The  intent  is  to 
provide  sound  HMI  practices  for  either:  satellite  operations  programs,  which  are  planning  upgrades, 
or  for  new  programs,  which  employ  operator  workstations  to  perform  any  satellite  operations 
activities. 

The  conventions  described  in  this  document  were  developed  to  be  as  flexible  as  possible,  while 
attempting  to  ensure  commonality  between  satellite  operations  systems.  Every  effort  has  been  made 
to  maximize  the  incorporation  of  basic  industry  standards,  existing/proven  program  designs,  and 
derive  specific  conventions  where  necessary  to  meet  unique  domain  requirements.  The  conventions 
are  based  upon  the  latest  Air  Force  Satellite  Control  Network  (AFSCN)  Employment  Concept 
(Department  of  the  Air  Force,  1996)  and  the  Functional  Task  Analysis  (FTA)  (Lockheed  Martin 
Mission  Systems,  1998).  The  FTA  captures  specific  tasks,  operator  decisions,  and  screen  content 
determined  to  be  necessary  to  accomplish  each  task.  These  conventions  are  also  consistent  with 
Volume  1  of  this  document  and  the  American  Institute  of  Aeronautics  and  Astronautics  (AIAA) 
Recommended  Practice  for  Human-Computer  Interface  for  Space  Systems  Operations  (HCISSO) 
[BSR/AIAA  R-023A-1995,  1995], 

1.1  Conventions  Document  Organization 

The  following  list  summarizes  the  organization  and  content  of  this  document: 

•  Section  1,  Overview;  provides  an  introduction  to  the  intended  use  of  these  conventions, 
definitions  of  the  individual  functional  areas  (domains)  in  satellite  operations,  and  high  level 
general  HMI  design  principles. 

•  Section  2,  Operator  Interaction;  presents  design  guidance  for  operator  interaction  with  the 
computer. 

•  Section  3,  Screen;  presents  conventions  for  the  screen  layout,  definition  of  each  zone, 
including  guidance  on  presentation  of  alert  information,  and  guidance  on  the  application  and 
use  of  color. 

•  Section  4,  Window;  presents  design  guidance  for  window  layout  and  window  elements, 
including  title  bars,  menus,  and  other  window  components. 

•  Section  5,  Help;  presents  guidance  for  providing  access  to  multiple  levels  and  kinds  of  on¬ 
line  help. 

•  Section  6,  Domain  Specific  Conventions;  presents  guidance  specific  to  application  of 
the  conventions  in  domain  operations. 

1.2  Domain  Overview 

The  following  sections  provide  an  overview  of  the  functional  areas  of  responsibility  (domains): 
Contact  Operations,  Mission  Planning,  Orbit/ Attitude  Management,  Engineering  Analysis,  Mission 
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Payload  Operations,  and  Operations  Support.  These  domains  contain  tasks  or  activities,  which  are 
considered  to  be  function  or  position  specific.  Functions  have  been  organized  into  these  domains  for 
ease  of  describing  display  conventions  in  this  document.  Depending  on  a  system’ s  operational 
concept,  functions  may  be  combined  into  one  or  more  positions  or  they  may  be  allocated  across 
positions. 

1.2.1  Contact  Operations 

The  Contact  Operations  Domain  consists  of  satellite  support  activities  to  include:  execution  of 
individual  satellite  contacts,  configuration/deconfiguration  of  resources,  execution  of  the  satellite 
support  plans  (SSPs),  in-procedure  anomaly  resolution,  status  reporting,  and  coordination  with 
external  agencies  as  required. 

1.2.2  Mission  Planning 

Mission  Planning  is  responsible  for  all  tasks  associated  with  non-real-time  scheduling  and  preparation 
of  support  to  meet  mission  requirements  of  a  satellite  constellation.  This  includes  keeping  track  of 
schedule-impacting,  long-term  satellite  control  network  outages,  maintaining  support  requirements 
catalogs,  preparing  long-term  support  schedules  for  satellite  constellation,  and  preparing  selected 
SSPs. 

1.2.3  Orbit/Attitude  Management 

Orbit/ Attitude  domain  activities  are  related  to  maintaining  each  satellite’s  correct  orbit  (path  through 
space)  and  attitude  (orientation  with  respect  to  the  Earth,  Sun  or  other  celestial  objects).  This  includes 
developing  orbit  and  attitude  state  vectors,  generating  ephemeris/event  products,  generating  orbit 
stationkeeping,  and  generating  attitude  maintenance  maneuvers.  Activities  also  include  producing 
station  visibilities,  Radio  Frequency  Interference  (RFI)  conjunction  projections,  predictions  of  close 
approach  to  other  space  objects  and  interfacing  with  Inter-Range  Operations  (IRO). 

1.2.4  Engineering  Analysis 

Satellite  Engineering  provides  the  technical  details  necessary  to  operate  complex  satellite  systems. 
This  includes  developing,  validating,  and  maintaining  a  library  of  SSPs,  monitoring  the  state  of  health 
of  assigned  satellites,  developing  anomaly  resolution  plans/satellite  safeing  procedures,  and  assisting 
in  out-of-procedure  anomaly  resolution. 

1.2.5  Mission  Payload  Operations 

The  tasks  required  to  perform  Mission  Payload  Operations  include  data  receipt,  processing,  analysis 
and  dissemination.  Although  the  processing  and  analysis  functions  relate  primarily  to  the  mission  data 
itself,  unique  display  requirements  may  also  exist  for  monitoring  and  controlling  payload  sensors  and 
on-board  processes.  Because  both  of  these  areas  are  highly  mission  unique,  the  intent  is  to  identify 
conventions  that  are  common  among  programs  and  can  be  applied  to  all  equally.  The  conventions  are 
therefore  at  a  higher  level  than  the  other  domains.  For  most  functions,  the  common  conventions,  as 
defined,  arc  sufficient.  The  conventions  captured  for  this  document  reflect  the  review  of  payload 
operations’  screens  from  Global  Positioning  System  (GPS),  Defense  Satellite  Communications 
System  (DSCS),  and  Space  Based  Infrared  System  (SBIRS). 
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1.2.6  Operations  Support 

Operations  support  includes  functions,  which  are  required  to  maintain  operations,  but  which  are  not 
directly  related  to  operational  control  of  satellites.  The  areas  included  in  this  domain  are:  system 
administration,  security  management,  database  management,  and  training/evaluation  for  satellite 
operations. 

1.3  Design  Principles 

In  general,  once  a  set  of  design  conventions  has  been  chosen,  it  should  be  followed  consistently 
within  the  application  and  across  applications  when  used  by  the  same  operator  position(s).  Not  all 
conventions  can  be  used  interchangeably.  Care  must  be  taken  to  select  the  tools  and  technologies 
which  use  complimentary  conventions.  For  example,  buttons  with  the  same  behavior  should  appear 
the  same  (See  Developer’s  Style  Guide)  and  the  placement  of  tool  bars  (Para.  3.1.4,  Toolbar)  should 
be  consistent  when  presented  to  an  operator. 

Listed  below  are  principles  to  be  applied  to  satellite  operations  screen  design: 

•  Minimize  the  number  of  windows  that  an  operator  must  access  to  perform  a  task. 

•  Minimize  operator  actions  that  must  be  performed. 

•  Have  alternative  methods  for  data  entry  and  selection  (i.e.,  have  at  least  two  methods  for 
inputting  information,  executing  actions,  and  making  selections). 

•  Minimize  operator  errors. 

•  Maximize  use  of  default  values. 

•  Utilize  option  menus  and  combo  boxes  to  reduce  data  entry  errors. 

•  Utilize  automatic  error  checking  procedures  as  much  as  possible. 

•  Maximize  reuse  and  efficiency  of  windows. 

•  Limit  information  displayed  to  ensure  a  clutter-free  appearance. 

•  Present  information  in  expected  locations,  e.g.,  left  to  right,  top-to-bottom  orientation. 

•  Present  information  in  a  consistent  format. 

•  Minimize  pointer  and  eye  movement  requirements. 

•  Present  information  simply  and  in  a  functionally-organized  manner. 

•  Aggregate  and  group  functionally  related  fields. 

•  Provide  clear  indications  of  interrelationships,  e.g.,  use  borders  or  frames  to  delineate  groups. 
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•  Use  color  purposefully  for  coding,  i.e.,  conveying  information  to  the  operator,  not  for 
decoration. 

•  Use  plain,  simple  language,  limit  use  of  acronyms  and  abbreviations. 

•  Provide  an  intuitive  way  to  navigate  through  the  system. 

•  Establish  acceptable  refresh  rates  for  indicating  status  and  monitoring  processes. 

•  Notify  operator  of  significant  system/status  changes,  as  in  alert  messages. 

•  Present  alert  messages  in  a  timely,  unambiguous  manner. 

•  Require  operator  acknowledgment  for  critical  notifications. 
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2.  Operator  Interaction 


This  section  identifies  conventions  and  display  design  guidance  for  operator  interaction  with  the 
computer.  Domain  unique  conventions  are  found  in  Para.  6,  Domain  Specific  Conventions. 

2.1  Pointing  Devices 

(Ref:  Para.  3. 1.2.3  of  ANSI/AIAA  R-023-1995  HCISSO  and  Para.  2.1.3  of  the  User  Interface 
Specifications  for  the  DII,  v.  3.0.  1998). 

2.1.1  Mouse  Keys 

The  following  default  mouse  key  assignments  are  provided  in  most  operating  environments.  Key 
assignments  can  be  defined  to  standardize  behaviors  across  applications  if  necessary. 

•  For  a  two  button  mouse: 

-  Left  button  (button  1)  -  selects,  moves,  and  makes  the  selected  field  or  window  the  active 
field  or  window. 

-  Right  button  (button  2)  -  pop-up  menu,  additional  information,  Help. 

-  <Shift>  button  1  -  adjusts. 

•  For  a  three  button  mouse: 

-  Left  button  (button  1)  -  selects,  moves,  and  makes  the  selected  field  or  window  the  active 
field  or  window. 

-  Middle  button  (button  2)  -  adjusts. 

-  Right  button  (button  3)  -  pop-up  menu,  additional  information,  Help. 

2.1.2  Touch  Interactive  Devices 

Touch  interactive  devices  permit  a  user  to  control  movement  of  a  pointer  and  select  options  with  a 
finger  or  another  device,  such  as  a  light  pen.  While  not  demonstrated  in  this  effort,  touch  interactive 
devices  can  only  be  used  when  limited  choices  are  presented  at  any  particular  time  and  the  choices  for 
selection  have  sufficient  separation  to  prevent  operator  error  in  selection. 

2.2  Voice  Input 

Voice  input  provides  a  natural  method  of  inputting  commands  or  directions  and  allows  for  no  hands 
operations.  Voice  input  requires  a  specific  lexicon,  feedback  confirming  spoken  entries,  and  an 
alternative  entry  method.  This  technology  is  not  recommended  for  mission  critical  and  time  critical 
directions  which  could  be  incorrectly  interpreted,  thus  causing  damage  to  the  system  or  unacceptable 
degradations  or  failures.  This  technology  was  not  demonstrated  in  this  effort.  See  Para.  3.3, 
Alternative  Input/Output  (I/O)  Devices,  of  the  DoD  HCI  Style  Guide,  for  design  considerations  when 
choosing  this  technology. 
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2.3  Navigation  Keys  and  Techniques 

Several  techniques  exist  for  experienced  users  to  rapidly  (rapidly  and  consistently)  access  certain 
functions  or  actions.  The  following  are  defined  in  greater  detail  below: 

•  Function  keys. 

•  Accelerator  keys. 

•  Mnemonics. 

The  same  function  keys,  accelerator  keys,  and  mnemonics  (shortcut  or  hot  keys)  are  not  to  be  used  for 
different  actions  within  a  domain;  or  across  domains/applications  if  assigned  to  a  single  operator 
position.  This  eliminates  the  chance  of  operator  error.  Note:  Domain  specific  shortcut  or  hot  keys  are 
defined  in  Para.  6,  Domain  Specific  Conventions. 

2.3.1  Function  Keys 

Table  2.1  presents  default  and  reserved  function  key  definitions  that  may  be  used  in  either  Motif  or 
Windows  design. 


Table  2.1.  Default  Function  Key  Definitions 


Function 

Key 

F  unction/Action 

FI 

Flelp  -  Access  to  Help  Menu 

F6 

Navigates  to  next  pane  of  active  window 

F7 

Reserved 

F8 

Reserved 

F9 

Reserved 

F10 

Navigates  to/from  a  menu  bar 

F12 

Print 

2.3.2  Accelerator  Keys 

Accelerator  keys  consist  of  a  modifier  key  (<Shift>,  <Alt>,  or  <Ctrl>)  and  some  other  key.  Table  2.2 
present  accelerator  keys  that  may  be  used  in  either  Motif  or  Windows  design. 


Table  2.2.  Default  Accelerator  Key  Definitions 


Accelerator 

Key 

Function/Action 

<Shift>  FI 

Context  Sensitive  Help 

<Alt>  F4 

Closes  current  active  window 

<Cntl>  P 

Print 
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2.3.3  Mnemonics 


Mnemonics  are  identified  by  underlining  a  single  character.  Normally  mnemonics  are  used  in  menu 
titles  and  menu  options.  All  menu  titles  and  options  have  a  mnemonic.  When  the  construct  (i.e., 
menu,  button,  or  other)  has  input  focus,  keyboard  entry  of  the  mnemonic  executes  the  selection.  Table 
2.3  presents  mnemonics  that  may  be  used  in  either  Motif  or  Windows  design. 


Table  2.3.  Default  Mnemonic  Definitions 


Mnemonic 

Key 

Function/  Action 

F 

File  menu 

H 

Help  menu 

S 

Save 

X 

Exit 

2.4  Screen/Window  Navigation 

There  are  several  methods  for  moving  around  in  a  screen  and/or  between  windows.  Use  the  method 
necessary  to  improve  operator  efficiency  in  performing  specific  tasks/operations. 

2.4.1  Display  Window  Navigation 

(Ref:  Para.  3.2.5.2  of  ANSI/A1AA  R-023-1995  HCISSO). 

Listed  below  are  conventions  specific  to  this  method: 

•  Point  and  click 

•  Push  Buttons 

•  Menu  actions  (availability  is  position  dependent)  using  point  and  click,  accelerator  keys 
function  keys,  and  mnemonics 

2.4.2  Keyboard  Navigation 

(Ref:  Para.  3.2.5. 1  of  ANSI/A1AA  R-023-1995  HCISSO). 

Listed  below  are  conventions  specific  to  this  method: 

•  Arrow  keys 

•  Tabs 

•  Command  Entry 
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(See  Command  Window,  Para.  9.1.7,  User  Interface  Specifications  for  the  DII,  v.  3.0,  1998). 

This  capability  is  generally  reserved  for  specialized  functions,  such  as  those  found  in  System 
Administration.  Note:  Operator  access  to  performing  command  entries  through  a  command  window  is 
limited  through  system  access  privileges. 

2.5  Use  of  Multiple  Windows  On  A  Single  Screen  Display 

Simultaneous  viewing  of  multiple  windows  provides  an  operator  access  to  information  from  multiple 
sources  or  applications.  The  following  rules  apply  for  use  of  multiple  windows  on  a  single  screen 
display: 

•  Windows  come  up  in  a  default-tiled  fashion  (no  overlapping)  whenever  feasible.  Sometimes, 
large  or  multiple  windows  preclude  tiling. 

•  Windows  within  the  work  zone  may  be  overlapped  or  cascaded  only  if  the  window  being 
covered  contains  informational,  non-critical  data,  and  is  not  necessary  to  the  operator  actions 
being  performed. 

•  Message,  confirmation,  and/or  file  retrieval  dialog  boxes  may  temporarily  overlay  the  current 
window  called  the  dialog  box. 

•  Application  and  use  of  cascading  or  tiled  windows  is  function/position  dependent  and  is 
presented  in  Para.  6,  Domain  Specific  Conventions 

2.6  Feedback 

(Ref:  Para.  3.4.3.4  of  ANSI/AIAA  R-023-1995  HCISSO  and  Para.  3.6.3,  3.6.5,  and  9.2  of  User 
Interface  Specifications  for  the  DII,  v.  3.0,  1998). 

Specific  to  Satellite  Operations  functional  requirements,  the  standard  definitions  for  process  status 
feedback  and  process  outcome  feedback  apply.  In  general,  the  system  provides  feedback  to  the 
operator  within  acceptable  response  times  and  using  acceptable  refresh  rates.  For  more  information 
see  Process  Status  Feedback  and  Process  Outcome  Feedback  in  the  Developer’s  Style  Guide. 
Feedback  in  the  form  of  pop-up  dialog  boxes  is  categorized  as  confirmation  pop-ups,  warning  pop- 
ups,  or  process  status  and  process  outcome  pop-ups.  The  use  of  pop-ups  is  to  be  minimized  to  reduce 
unnecessary  operator  actions. 

Confirmation  pop-ups  are  used  only  in  real  time.  They  indicate:  (1)  that  data  will  be  lost  during  a 
Close  or  Exit  operation,  (2)  termination  of  a  process  when  another  method  was  used  to  discontinue 
the  process  than  a  process  status  pop-up,  (3)  when  an  SSP  is  terminated  unexpectedly,  (4)  an  explicit 
destruction  for  which  recovery  is  not  possible,  or  (5)  a  critical  action. 

Warning  pop-ups  are  only  used  when  no  other  actions  can  be  taken  until  the  operator  acknowledges 
the  message.  An  audible  notification  (see  p.  1 1)  accompanies  all  warning  pop-ups.  Note:  A  warning  is 
an  alert  and  most  alerts  are  presented  in  the  alert  area  (see  Para.  3. 1.3.2,  Alert  Area). 


Process  status  and  process  outcome  pop-ups  don’t  require  a  response  from  the  operator.  Initial 
placement  should  minimize  covering  active  windows.  Operators  can  also  move  process  status  and 
process  outcome  pop-ups. 

2.7  Recovery 

(Ref:  Para.  3.6.6  of  User  Interface  Specifications  for  the  DII,  v.  3.0,  1998) 

General  undo  capabilities  are  provided  for  reversing  actions  (i.e.,  drag  transfers,  clipboard  transfer, 
deleting  of  data,  etc.),  unless  a  confirmation  pop-up  is  used  prior  to  action  initiation.  Actions  that 
cannot  be  reversed  are  labeled  appropriately  and  separated  from  actions  that  can  be  reversed.  If  a 
multiple  level  undo  capability  (i.e.,  reverses  a  series  of  previous  actions)  is  provided,  a  Redo 
capability  is  also  supported  for  reversing  the  most  recently  undone  action. 
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3.  Screen 


The  following  sections  describe  conventions  specific  to  screen  layout  and  screen  colors. 

3.1  Screen  Layout 

(Ref:  Para.  3.2.1.2  of  ANSI/AIAA  R-023-1995  HCISSO) 

In  accordance  with  the  ANSI/AIAA  HCISSO  there  are  5  zones:  the  header  zone,  the  status  zone,  the 
toolbar,  the  work  zone,  and  footer  zone.  Information  typically  contained  in  a  footer  zone  is  displayed 
in  the  status  area  or  on  individual  windows  in  the  work  zone.  Also  none  of  the  Commercial  Off  the 
Shelf  (COTS)  products  or  programs  examined  during  this  effort  incorporated  a  footer  zone  in  their 
design.  For  these  reasons,  the  footer  zone  is  not  implemented  in  these  conventions.  Figure  3-1 
presents  an  example  of  the  overall  screen  layout.  Some  of  the  zone  or  component  placements  are 
optional.  Refer  to  the  paragraphs  on  each  zone  for  details  on  required  and  optional  layouts. 


Header  (system,  user,  classification,  mode  &  date/time) 

Domain 

l- _ 1 

Status 

t _ 1 

Alert  Area 

1 _ — L _ 1 

Alerts,  Warnings  and  Events 
appear 


Desktop  or  Work  Zone 


!  Toolbar  provides  a  launching  point  for  applications  and  access  to  other  workspaces 


Toolbar 


Schedule  and  High  Level  Status 
crucial  to 


Figure  3.1.  Screen  Layout. 

3.1.1  Zone  Manipulation 

Screens  and  windows  can  be  reconfigured  by  designated  crew  or  personnel  to  meet  specific  mission 
or  operational  requirements.  Some  windows/zones  cannot  be  reconfigured  due  to  the  specific  mission 
or  operational  requirements.  Minimization/iconification  and  recommended  configurations  can  be 
found  in  Para.  6,  Domain  Specific  Conventions. 

3.1.2  Header  Zone 

The  following  sections  describe  conventions  specific  to  header  zone  characteristics  and  contents  as 
well  as  dual  display  head  considerations. 
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3. 1.2.1 


Characteristics  and  Content 


The  header  zone  is  a  reserved  area,  which  appears  at  the  top  of  the  display  screen.  The  header  zone 
cannot  be  overwritten  or  covered.  It  contains:  system  identification  information,  user  or  position 
identification  (optional),  security  classification,  mode  indicator,  and  date-time  group.  These  items  are 
displayed  in  the  order  listed  with  the  classification  centered  on  the  screen  (see  Figure  3-2).  Each  item 
is  displayed  in  an  output  field: 


•  System  ID  -  Shows  software  type  and  version  and  Satellite  system,  SOC,  or  Mission  Control 
Complex  (MCC)  ID 

•  User  or  Position  ID  -  Shows  who  is  currently  logged  into  the  system  (optional) 

•  Classification  -  Shows  the  highest  classification  of  the  system  (see  Para.  3.2.3,  Classification 
Colors  in  Screen  Header) 

•  Mode  Indicator  -  Shows  the  current  mode  of  operations  (i.e.,  Simulation,  Test,  Operational, 
etc.) 

•  Date/Time  -  Shows  the  current  date/time  group  (format  selectable,  Zulu  time  is  recommended 
as  default) 


Figure  3.2.  Header  and  Status  Zone  Example. 

3.1. 2.2  Multiple  Display  Considerations 

Three  alternatives  exist  for  displaying  the  header  zone  when  multiple  display  heads 
(monitors)  are  being  used. 

Alternative  1  -  Display  header  zone  only  on  one  of  the  display  heads. 

Alternative  2  -  Display  header  zone  in  entirety  on  all  display  heads. 

Alternative  3  -  Display  header  zone  in  entirety  on  one  display  head  and  display  the 

classification  field  at  the  top  center  of  the  other  display  heads. 

3.1.3  Status  Zone 

The  status  zone  consists  of  two  primary  areas:  the  status  area  and  the  alert  area.  The  status  zone  is 
displayed  at  the  top  of  the  screen,  just  below  the  screen  header  zone.  The  entire  screen  width  (left  to 
right)  is  used;  however,  the  depth  or  number  of  lines  may  be  tailored  to  specific  functions  or 
positions.  See  Para.  6,  Domain  Specific  Conventions  for  display  and  configuration  details. 
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•  Status  area  (left  _  to  _  of  screen  width) 

•  Alert  area  (right  __  to  _  of  screen  width) 

3. 1.3.1  Status  Area 

The  status  area  provides  high  level  information  on  items  or  activities  which  are  crucial  to  operations 
and  must  be  constantly  visible.  The  following  specific  types  of  information  may  be  displayed.  More 
detailed  descriptions  of  status  area  content  are  presented  in  Paragraph  6,  Domain  Specific 
Conventions. 

•  Scheduled  Activities  -  may  include  items  such  as  upcoming  satellite  contacts  or  tasks  to  be 
performed 

•  Resource  Status  -  may  contain  constellation,  satellite,  ground  station,  communication  or 
system  elements 

•  Process/ Activity  Status-  may  contain  real  time  or  offline  process  status 

•  Summary  Status-  may  contain  high  level  summary  as  in  operational  capability  (OPSCAP) 
and  situation  status 

•  Domain  specific  status 

3.1. 3.2  Alert  Area 

This  area  presents  notification  messages  to  the  operator  for  review  and  for  action  as  required.  Alerts 
are  initially  presented  in  the  Alert  Area  (Alert  Window).  From  the  alert  area  an  expanded  view  of  all 
current  alerts  can  be  invoked.  Once  alerts  have  been  acknowledged  and  removed  from  the  alert  area, 
they  are  retained  in  the  Alert  History  file. 

Notification  messages  are  called  alerts  and  include  four  specific  types  based  on  criticality:  alarms, 
warnings,  events,  and  informational  messages.  Alarms  are  the  most  severe  and  are  color  coded  red 
(severe  or  critical  problem  or  outage).  Warnings  are  next  in  importance  and  are  color  coded  yellow 
(degradation).  Events  and  informational  messages  are  colored  white  or  green:  green  if  a  status  is 
being  reported,  e.g.,  configuration  change  or  an  element  is  back  on-line;  white  if  a  process  has 
finished  running.  Other  alert  area  attributes  include:  counters  to  assess  number  of  alerts  in  the  system 
and  their  distribution  across  categories,  assignment  of  audible  notifications  as  determined  by 
criticality,  the  informational  (text)  message  for  each  alert,  and  methods  of  acknowledging  alerts.  A 
program  may  choose  to  define  whether  or  not  the  informational  message  category  is  required  for  their 
purposes.  Specifics  concerning  the  use  and  content  of  the  Alert  area  and  the  detailed  alert  information 
are  listed  in  the  Para.  6,  Domain  Specific  Conventions. 

3.1 .3.2.1  Alert  Area  Window 

The  following  specific  details  about  the  Alert  Area  window  apply  across  all  domains: 
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•  Minimum  alert  content  of  the  Alert  Area  window  includes:  counters  for  message  types,  alerts 
requiring  acknowledgment,  an  acknowledge  button  or  capability,  and  a  capability  to  access 
more  detailed  text  on  a  specific  alert. 

•  Alert  messages  contain  information  source,  date -time  group,  and  description;  in  that  order 
(date  may  or  may  not  be  displayed). 

•  Alerts  are  color-coded  based  on  criticality  (see  Table  3.2,  Color  Usage  Definitions). 

•  All  alerts  can  have  an  associated  audible  signal  upon  initial  posting.  Typically  only  alerts 
containing  critical  information  (i.e.,  alarms)  have  an  associated  audible  signal  (See  Para. 

3. 4.2. 3,  Audible  Alarm  Notifications,  of  the  ANSI/AIAA  R-023-1995  HCISSO). 

•  An  operator  has  the  capability  to  acknowledge  an  alert. 

•  Once  an  alert  is  acknowledged,  it  is  automatically  sent  to  an  alert  history.  (Optional:  It  may 
be  desirable  for  a  program  to  allow  the  operator  to  manage  when  an  alert  is  taken  out  of  the 
active  queue  and  stored  in  another  location.) 

•  The  alert  area  (window)  provides  access  to  more  information  on  individual  alerts. 

•  Counters  for  all  message  types  (e.g.,  alarms,  warnings,  events,  and  informational  messages) 
are  shown  in  the  Alert  Area  and  the  Expanded  Alert  window. 

•  Alerts  are  presented  in  an  order  set  by  the  user  (program  or  SOC).  Some  of  the  possible 
options  for  setting  the  order  are  based  on  criticality,  time,  source,  or  subsystem.  Suggested 
default  order  is  by  criticality  first  and  then  by  time,  with  the  most  recent  alarm  being 
presented  first  and  the  oldest  informational  message  being  presented  last. 

•  Alerts  may  be  grouped  to  separate  alarms  and  warnings  from  other  non-critical  alerts  (events 
and  informational  messages). 

3.1. 3.2.2  Expanded  Alert  and  Alert  History  Windows 

The  following  specific  details  apply  to  the  Expanded  Alert  window  or  the  Alert  History  window: 

•  The  expanded  window,  when  used,  is  placed  immediately  under  the  Alert  Area  window. 

•  The  Expanded  Alert  window  provides  a  view  of  all  current  alerts  and  is  invoked  from  the 
Alert  Area. 

•  The  Alert  History  contains  all  past  alerts  that  arc  not  in  the  current  Alert  Area  window  and  is 
invoked  from  either  the  Expanded  Alert  window  or  the  screen  Toolbar. 

•  Both  the  Expanded  Alert  window  and  the  Alert  History  have  multiple  sort  options,  such  as 
criticality,  time,  and  source  or  subsystem. 

•  The  Expanded  Alert  window  provides  access  to  the  Alert  History. 
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•  Messages  not  requiring  acknowledgment  may  be  displayed  only  in  the  Expanded  Alert 
window  (in  lieu  of  the  alert  area  window,  see  program  operational  concept). 

3.1.4  Toolbar 

The  screen  toolbar,  as  displayed  in  Figure  3.3,  is  used  as  a  launch  point  for  applications  and  windows. 
Placement  of  the  toolbar  may  be  at  the  bottom  of  the  screen  to  free  up  workspace  and  prevent 
confusion  with  the  status  zone.  Other  placements  include  immediately  below  the  status  zone  and 
between  the  header  and  status  zones.  Placement  below  the  status  zone  avoids  covering  items  in  the 
status  zone.  Placement  between  the  header  and  status  zones  causes  some  items  in  the  status  zone  to  be 
temporarily  covered,  when  menus  in  the  toolbar  are  open.  However,  some  systems  require  placement 
immediately  under  the  header  zone,  above  the  status  zone,  to  minimize  changes  to  COTS  products. 
The  toolbar  can  contain  menu  items  (e.g.,  File;  Help,  etc.)  or  specific  function  icons  which  launch 
applications  (e.g.,  command  generation;  telemetry  evaluation,  etc.).  The  toolbar  may  allow  for 
multiple  workspaces  to  be  identified  for  different  satellites  or  resources  (such  as  in  Common  Desktop 
Environment)  thus  allowing  the  operator  to  switch  between  different  workspaces  without  closing 
those  workspaces.  Toolbar  recommendations  and  specific  contents  are  listed  in  Para.  6,  Domain 
Specific  Conventions. 


Figure  3.3.  Toolbar  Example. 

3.1.5  Work  Zone 

(Ref:  Appendix  E,  Para.  3.2.I.2.F.  of  ANSI/AIAA  R-023-1995  HCISSO) 

The  work  zone  is  the  area  used  to  present  window  and  application  data.  This  zone  is  used  to  provide 
operator  access  to  the  functions  in  an  application.  The  work  zone  does  not  overlap  any  of  the  other 
zones.  It  is  sized  appropriately  to  contain  all  the  windows  and  application  data  needed  for 
accomplishment  of  the  mission. 

3.1. 5.1  Explicit  Focus  Model 

(Ref:  Para.  2.1.2  of  OSF  Motif  Style  Guide,  v.1.2,  Para.  3.1  and  7.2.3  of  the  User  Interface 
Specifications  for  the  DII,  v.  3.0,  1998) 

The  explicit  focus  model  is  the  recommended  method  for  changing  input  focus  between  windows  or 
components  in  a  window,  because  accidental  operator  entries  are  not  as  prevalent  as  with  the  implicit 
focus  model.  Input  focus  indicates  the  window  or  component  within  a  window  that  receives  operator 
or  keyboard  inputs.  In  the  explicit  focus  model,  input  focus  is  gained  by  clicking  or  selecting  any 
portion  of  a  window,  which  also  raises  the  window  to  the  front.  Requiring  operators  to  click  or  select 
only  certain  portions  of  a  window  (e.g.,  the  window  title  bar)  is  not  recommended. 
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3. 1.5.2  Cursor  Position 


The  default  cursor  position  in  a  window  is  at  the  beginning  of  the  first  data  entry  field.  A  double  click 
in  a  window,  to  apply  input  focus,  positions  the  cursor  at  the  nearest  input  field  to  the  location 
clicked. 

3.1. 5.3  Multiple  Displays 

Several  program  specific  operational  concepts  require  the  use  of  more  than  one  display  head 
(monitor)  in  their  implementation  to  maximize  the  screen  space.  When  multiple  displays  are  used  the 
windows  and  data  should  not  be  broken  (separated)  across  displays,  but  fully  contained  within  the 
work  zone  of  one  display. 

3.2  Screen  Colors 

(Ref:  Para.  3.2. 1.4,  ANSI/A1AA  R-023-1995  HCISSO) 

The  colors  presented  in  Table  3.1  are  used  in  various  combinations  to  identify  button  and  field  types 
and  indicate  status.  Color  is  consistently  applied  within  and  across  functional  areas  (domains). 
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Table  3.1.  Color  Definitions 


Color 

Description  of  Use 

Green 

Used  in  on-line  and  off-line  buttons,  input  and 
output  fields,  and  on  icons.  Used  on  borders,  top 
and  left  side  (half)  borders,  and  fill.  Always 
indicates  good,  normal,  or  operational  status. 

Yellow 

Used  in  on-line  and  off-line  buttons,  input  and 
output  fields,  and  on  icons.  Presented  as  borders 
or  borders  and  fill.  Always  indicates  a  warning  or 
degraded  condition. 

Red 

Used  in  on-line  and  off-line  buttons,  input  and 
output  fields,  and  on  icons.  Presented  as  borders 
or  borders  and  fill.  Indicates  alarm,  critical  status, 
or  non-operational  status. 

Graying-Out 

Indication  for  an  inactive,  unusable,  or  non- 
modifiable  construct.  Used  in  buttons,  text  fields, 
menu  choices,  and  more. 

White 

(1)  Indicates  an  unknown  state  when  applied  to  a 
button.  (2)  Also  used  as  fill  in  data  entry 
(modifiable)  fields.  (3)  Not  used  for  status. 

3.2.1  Usage  of  Screen  Colors 

Status  can  be  indicated  using  borders,  fill,  or  combinations  of  borders  and  fill.  Distinctions  between 
on-line  and  off-line  systems  are  made  with  fills  and  text.  Avoid  use  of  colored  text  (Ref:  Para. 
3.2.1.4.G,  Alert  Message  Coloring,  of  the  ANSI/A1AA  R-0231995,  HCISSO).  Figure  3-4  is  an 
example  of  a  combination  of  borders,  fill,  and  text  used  on  buttons  and  in  fields  (input  and  output 
fields)  to  indicate  status.  Table  3.2  defines  the  example  presented  in  Figure  3-4. 
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Figure  3.4.  Example  of  Color  Usage. 
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Table  3.2.  Color  Usage  Definitions 


Buttons  (appear  raised) 

Components 

Unknown 

Good 

Degraded 

Critical 

*On-Line  System 

Border:  Fill: 

**Text: 

White  White 
Black 

Green  Gray 
Black 

Yellow 

Yellow  Black 

Red  Red 
Black 

*Off-Line  System 

Border:  Fill: 

**Text: 

Gray  Gray 
Dark  Gray 

Green  Gray 
Dark  Gray 

Yellow  Gray 
Dark  Gray 

Red  Gray 
Dark  Gray 

Fields  (appear  sunken) 

Unknown 

Good 

Degraded 

Critical 

Output 

Fill:  Text:  Inside 
Border/Shadow: 

Gray  Dark 
Gray  None 

Gray  Black 
Green 

Yellow  Black 
None 

Red  Black 
None 

No  Entry 

Valid  Entry 

Invalid  Entry 

Input 

***Fill:  Text: 

Inside 

Border/Shadow: 

White  None 

None 

White  Black 

None 

White  Black  Red  Indicated 
by  a  distinctive  method  **** 
Error  Message 

Good 

Degraded 

Critical 

Icon 

Fill: 

Green 

Yellow 

Red 

Message 

Event 

Warning 

Alarm 

Alert  Acknowledge 

Button 

Fill: 

None 

White 

Yellow 

Red 

*  Use  of  an  icon  within  a  button  to  indicate  status  can  be  used  in  place  of  border  or  fill.  Use  of  the 
icon  must  not  degrade  and  must  enhance  readability.  **  There  must  be  a  reasonable  distinction 
between  gray  and  black  text.  Note:  Gray  text  is  darker  and  distinguishable  from  background  color. 
Font  size  may  also  be  used  to  help  further  distinguish  between  online  and  off-line  systems.  ***  Use  a 
different  shade  of  gray  from  that  used  in  Output  Fields,  this  minimizes  visual  noise  caused  by  large 
white  input  fields  and  still  distinguish  them  from  output  fields.  ****  Error  message  (optional)  and 
error  check  occurrence  depends  on  the  needs  of  the  particular-  function/task,  but  only  the  listed 
options  are  available  (e.g.,  Red  border  or  pop-up  window).  An  error  check  must  occur  and  the 
criticality  of  the  action  drives  the  resulting  level  of  error  flag. 

3.2.2.  Background  Color/Pattern 

Use  neutral  colors  (unsaturated  hues,  e.g.,  pastel  colors  or  light  gray)  providing  sufficient  color 
difference  to  distinguish  between  screen  desktop  and  windows  displayed  on  screen.  An  exception  to 
this  is  the  case  in  which  mission  payload  operations  require  the  use  of  dark  background  colors  to 
effectively  display  mission  data  as  opposed  to  textual  or  numeric  information  (e.g.,  Defense  Support 
Program  (DSP)  and  SB1RS). 
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3.2.3  Classification  Colors  in  Screen  Header 


(Ref:  Appendix  E.  Para.  3.2.I.4.I.  of  ANSI/AIAA  R-023-1995  HCISSO  and  Appendix  E,  Para.  E.l, 
of  the  User  Interface  Specifications  for  the  DII,  v.  3.0,  1998) 

The  colors  presented  in  Table  3.3  are  used  to  indicate  classification  of  screen  data.  Note  that  the 
methods  of  indicating  classification  are  borders  or  fill.  One  or  the  other  method  may  be  used; 
however,  a  combination  of  the  styles  as  listed  below  draws  more  attention  to  everything  classified 
confidential  or  higher  and  is  preferred  when  supported  by  the  GUI  tool. 

Table  3.3.  Classification  Colors 


Classification 

Color  Name 

Specific  Color 

Preferred  Style 

Unclassified 

Forest  Green 

34,  139,  34 

Green  Border 

Confidential 

Sky  Blue 

135,  206, 235 

Blue  Fill 

Secret 

Firebrick  2 

238,  44,  44 

Red  Fill 

Top  Secret 

Dark  Orange 

255,  140,  0 

Orange  Fill 

Special 

Compartmented 

Information 

*  Yellow 

* 

Yellow  Fill 

*  Color  is  not  specially  defined  in  User  Interface  Specifications  for  the  DII,  v.  3.0,  1998. 

3.2.4  Other  Users  of  Colors/Patterns 

Use  of  color  coding  or  patterns  is  allowed  and  recommended  to  identify  between  windows  running 
the  same  activity  or  vehicle  specific  function.  When  used,  pastel  colors  are  displayed  in  the  title  bar. 
For  example,  color  coding  title  bars  of  windows  associated  with  particular  space  vehicles  can 
facilitate  operator  recognition  when  windows  from  multiple  contacts  are  open  on  the  screen. 

Avoid  use  of  basic  status  colors  such  as  green,  yellow,  and  red  for  non-status  items.  Mission  payload 
data  (as  in  SBIRS)  is  an  example  of  non-status  data  in  which  data  discrimination  is  necessary  and 
may  require  the  use  of  the  full  color  pallet,  including  green,  yellow,  and  red.  Patterns  may  also  be 
used  to  further  distinguish  activities  when  colors  are  not  sufficient. 

3.2.5  Color  Graphics 

Lines  which  connect  graphical  elements,  as  in  dynamic  and  interactive  configuration  diagrams,  may 
be  color-coded  consistent  with  the  status  of  the  elements  in  the  indicated  path  (e.g.,  good  [green], 
degraded  [yellow],  non-operational  [red],  on-line  [green  or  black],  and  off-line  [grayed-out]). 
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4.  Window 


In  general,  minimize  use  of  buttons  to  simplify  screens  when  possible.  The  following  sections 
describe  conventions  specific  to  window  layout  and  window  components.  Note:  Dialog  boxes  are 
windows  for  specific  purposes  and  follow  the  same  conventions  used  for  windows. 

4.1  Window  Layout 

(Ref:  Para.  4.2.1.3  of  ANSI/AIAA  R-023-1995  HCISSO) 

All  windows  have  the  basic  window  functionality  controls  (i.e.,  resize,  maximize,  minimize,  and 
window  menu  button).  In  some  domains  a  minimum  size  is  set  to  ensure  all  data  can  be  read  legibly. 
Figure  4.1  presents  an  example  window  layout. 


Window  Menu  Button 


Window  Title  -w 

- 


Menu  Bar  (Optional) 


Window 

Frame 


A, 


One  Line  Title  Bar 
Two  Lines  (Optional) 


■  Application  Area 


Minimize 
Button 


Maximize 
Button 


Resize 

Border 


I 


Figure  4.1.  Window  Layout. 

4.2  Window  Elements 

The  basic  window  consists  of  the  following  elements:  window  frame,  sizing  and  placement  controls, 
window  title  bars  and  window  design  components. 

4.2.1  Window  Controls 

Window  control  buttons  include  the  window  menu  button  on  the  left  side  of  the  title  bar  and  the 
minimize  and  maximize  buttons  on  the  right  side  of  the  title  bar.  These  provide  basic  window 
functionality  and  are  common  to  all  windows  except  dialog  boxes.  Most  dialog  boxes  include  only 
the  window  menu  button.  The  window  menu  provides  access  to  window  management  functions,  such 
as:  restore,  move,  minimize,  maximize,  lower,  and  close. 


21 


4.2.2  Title  Bar 


The  title  bar  is  consistently  displayed  at  the  top  of  the  window  and  may  contain  two  lines. 

Figures  4.2  and  4.3  show  examples  of  a  one  line  and  a  two  line  title  bar.  The  following 
alternative  naming  conventions  are  available: 

Alternative  1  -  Descriptive  name  centered  in  the  title  bar  (name  should  match  name  of 
action  that  invoked  window). 

Alternative  2  -  Title  of  parent  window  followed  by  a  dash  and  the  name  of  the 
subwindow  beginning  at  the  left  side  of  the  title  bar. 

Alternative  3  -  Title  of  application  or  thread  centered  in  first  line  and  name  of  current  window 
centered  on  the  second  line. 

The  title  bar  may  contain  the  window’s  title,  purpose,  task  performed,  satellite  vehicle  controlled, 
remote  ground  facility,  resource  designator,  and  date-time.  The  information  in  the  second  line  (if 
displayed)  is  function-dependent.  However,  display  the  information  consistently  across  screen 
elements.  Classification  may  also  be  displayed,  if  required,  but  it  is  typically  only  indicated  in  the 
screen  header  zone.  When  used,  classification  appears  centered  in  the  top  most  portion  of  the 
window.  Display  fields  are  contained  within  the  window  display  status  in  accordance  with  the  color 
matrix  in  Table  3.2,  Color  Usage  Definitions.  When  the  satellite  identifier,  resource  designator, 
and/or  time  are  appropriate  to  display,  they  are  located  as  described  below: 

•  Satellite  Identifier  -  always  left  side  of  title  bar 

•  Resource  -  left  side  of  title  bar  and  if  applicable  on  right  side  of  satellite  identifier 

•  Time  -  function/position  dependent  format,  right  side  of  title  bar 


-  |  IRON/S ite  Title  -  Purpose 

Date  -  Time  1  |D 

Figure  4.2.  One  Line  Title  Bar  Example. 

"^1  Title 

IRON/Site  Purpose 

Date  -  Time 

Figure  4.3.  Two  Line  Title  Bar  Example. 
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4.2.3  Window  Design  Components 

The  following  paragraphs  reference  source  information  and  list  a  summary  of  attributes  for  each 
component.  Refer  to  referenced  data  or  the  Developer’s  Style  Guide  for  more  details. 

4.2. 3.1  Menu  Design 

(Ref:  Para.  3.1.3.1  of  ANSI/A1AA  R-023-1995  HC1SSO  and  Para.  5.0  and  8.1.2  of  User  Interface 
Specification  for  the  DII,  v.  3.0,  1998) 

Paragraphs  in  this  section  describe  conventions  specific  to  menu  design  such  as:  menu  bar,  pull-down 
menus,  submenus,  pop-up  menus,  tear-off  menus,  option  menus,  and  design  considerations. 

4.2. 3.1.1  Menu  Bar  Conventions 

Specifics  on  what  is  contained  in  a  menu  bar  can  be  found  in  Para.  6,  Domain  Specific  Conventions. 
The  following  are  menu  bar  characteristics: 

•  Located  immediately  below  the  title  bar 

•  Contain  cascade  buttons  arranged  side-by-side  horizontally 

•  The  cascade  buttons  have  a  textual  label  and  no  graphic 

•  The  text  label  in  each  cascade  button  is  a  menu  title 

•  A  menu  bar  contains  no  more  than  10  menu  titles  (cascade  buttons) 

•  When  not  selected  the  cascade  buttons  have  no  visible  border.  The  horizontal  group  of 
cascade  buttons  appears  as  a  list 

•  When  selected  the  cascade  button  border  is  visible  and  the  button  appears  raised 
The  menu  bar  contains  the  following  menu  options  and  actions: 

a)  File  (if  applicable)  -  far  left  of  menu  bar 

b)  Help  (if  applicable)  -  far  right  of  menu  bar 

c)  Other  menus/actions  as  required 

4.2. 3.1. 2  Pull-Down  Menu  Conventions 

•  Provide  quick  and  consistent  access  to  actions,  submenus,  and  settings  for  parameters. 

•  Consists  of  a  cascade  button,  which  is  also  the  menu  title,  that  when  activated  displays  a  set 
of  options  either  below,  beside,  or  above  the  button. 
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4.2.3.1 


4.2. 3.1 


4.2. 3.1 


4.2.3.1 


The  options  can  be  actions,  routings  to  a  window  or  submenu,  or  settings  that  define 
parameters. 

Contains  no  less  than  2  and  no  more  than  15  options  (Para.  5.5.3,  Grouping  into  Menus  and 
Submenus,  of  the  Dll,  v.  3.0,  1998). 

After  a  selection  is  made  the  menu  is  closed. 

.3  Submenu  Conventions 

A  child  of  a  pull-down  or  tear-off  menu  is  invoked  by  selecting  an  option  in  a  menu. 
Submenus  are  limited  to  two  levels  below  the  parent  menu  option. 

Submenus  contain  at  least  three  options;  otherwise,  the  options  are  placed  in  the  parent  menu. 
After  a  selection  is  made,  the  menu  is  closed. 

.4  Pop-Up  Menu  Conventions 

Provide  the  experienced  user  with  a  quick  way  to  perform  common  tasks  on  individual 
elements. 

Is  hidden  from  the  user  and  is  posted  (activated)  by  clicking  the  right  mouse  button  or  other 
action. 

Options  can  be  accessed  elsewhere  in  the  application. 

After  a  selection  is  made  the  menu  is  closed. 

In  Motif,  the  menu  includes  a  title  separated  from  the  first  menu  option  by  a  separator  line 
In  windows,  a  title  is  not  needed. 

.5  Tear-Off  Menus  Conventions 

Used  when  selections  are  made  repeatedly  from  a  pull-down  menu,  submenu,  or  popup  menu. 
Appear  as  other  menus  (pull-down,  submenu,  or  pop-up). 

Has  a  tear-off  button  either  before  the  list  of  options  or  after  the  title. 

Tear-off  button  contains  a  dashed  line  graphic  that  indicates  the  tear-off  action. 

After  a  selection  is  made  the  menu  remains  open. 

.6  Option  Menus  Conventions 

Used  to  select  from  a  discrete  set  of  values  or  choices  that  are  not  likely  to  change. 
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•  When  used,  the  currently  selected  option  replaces  the  text  field  in  the  button. 

•  When  used,  the  Option  menu  label  is  placed  either  above  or  to  the  left  of  the  button. 

•  Selection  of  the  arrow  graphic,  which  is  placed  on  the  right  side  of  the  text  field,  activates  the 
menu. 

•  Upon  activation,  the  options  are  displayed  in  a  list  box  or  scrollable  list  box. 

•  Selections  are  made  by  depressing  and  holding  the  right  mouse  button  until  the  desired  option 
is  highlighted  and  then  releasing  the  mouse  button. 

•  Not  used  for  critical  choices,  because  unintentional  selections  can  be  made. 

•  Used  when  the  number  of  choices  (options)  does  not  exceed  12. 

4.2.3.1.7  Menu  Design  Guidance  for  All  Menus 

•  One  option  is  displayed  per  line  and  the  first  letter  of  each  word  is  capitalized. 

•  All  menu  titles  and  menu  options  have  mnemonics.  For  example:  Save 

•  Frequently  used  menu  options  have  accelerator  keys.  For  example:  <Ctrl>  S 

•  Separators  are  used  to  delineate  groups  of  options. 

•  Menu  or  option  selection  is  identified  by  highlighting. 

4.2. 3.2  Label  Conventions 

•  A  label  is  a  text  descriptor  for  a  button,  input  field,  output  field,  option  menu,  or  section  of 
window. 

•  Label  background  color  is  the  same  as  window  background  color. 

•  Default  text  color  is  black. 

•  Text  labels  are  aligned  on  the  left  most  character. 

•  Numeric  labels  are  aligned  on  the  decimal  point. 

4.2. 3.3  Input  Field  Conventions 

(Ref.  Para.  6.8  of  the  User  Interface  Specification  for  the  DII,  v.  3.0,  1998) 

•  Appears  sunken. 

•  Input  (editable)  fields  contain  white  or  cream  colored  fill. 
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•  Multiple  line  input  fields  contain  a  darker  gray  fill  than  output  fields  and  the  window 
background.  This  reduces  visual  noise  caused  by  large  white  fields  and  still  distinguishes 
input  fields  from  output  fields. 

•  Status  can  be  indicated  through  use  of  borders,  see  Table  3.2,  Color  Usage  Definitions. 

•  The  default  cursor  position  is  on  the  left  most  character  or  number.  However,  entry  at  any 
point  in  the  field  is  allowed. 

•  Text  is  left  justified. 

•  Numeric  fields  are  right  justified  and  columns  are  aligned  on  the  decimal  point. 

4.2. 3.3.1  Combo  Box  Conventions 

(Ref.  Para.  6.1 1  of  the  User  Interface  Specification  for  the  Dll,  v.  3.0,  1998) 

•  Used  to  either  enter  a  value  or  option  or  to  select  from  a  list  of  values  or  options  in  a  list. 

•  Allows  text  entry  in  the  text  field  and/or  selection  of  an  option  (item)  from  the  list  box  or 
scrollable  list  box. 

•  Contains  a  left  justified  text  field  and  an  arrow  button  (small  push  button)  on  the  right  side 
that  activates  a  list  box.  See  Option  Menu  for  more  detail  on  the  list  box,  activation,  and 
option  selection. 

4.2.3.3.2  Linked  Input  Field  Conventions 

•  Used  when  values  of  a  parameter  arc  frequently  displayed  in  different  units. 

•  Consists  of  two  input  fields  that  are  linked  by  a  mathematical  relationship  or  some  other 
relationship. 

•  After  a  value  is  entered  or  edited  in  one  of  the  fields,  a  corresponding  value  is  displayed  in 
the  other  field. 

4.2. 3.3.3  Display  Input  Field  Conventions 

•  Used  for  verification  purposes. 

•  Consists  of  two  fields:  an  input  field  and  an  output  field. 

•  The  output  field  is  placed  directly  under  the  input  field. 

•  Entries  are  made  in  the  input  field. 

•  After  entries  have  been  made  they  are  displayed  in  the  output  field. 
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4.2. 3.4 


Output  Field  Conventions 


•  Appears  Sunken. 

•  Output  fields  are  distinguished  with  gray  fill  (the  same  color  as  the  window  background). 

•  Status  indications  through  use  of  borders,  fill,  and  combinations  of  both,  see  Table  3.2,  Color 
Usage  Definitions. 

•  Textual  output  fields  are  left  justified  and  columns  of  textual  output  fields  are  aligned  on  the 
first  character. 

•  Numeric  output  fields  are  right  justified  and  columns  of  numeric  output  fields  are  aligned  on 
the  decimal  point. 

•  If  more  than  a  single  line  of  data  needs  to  be  displayed,  scroll  bars  (vertical)  are  added  to 
facilitate  scrolling  of  the  viewable  area.  Note:  Avoid  use  of  horizontal  scroll  bars,  only  added 
as  a  last  resort. 

4.2. 3.4.1  Scrollable  Table 

•  Appears  as  a  multiple  line  output  field  with  multiple  columns. 

•  May  indicate  separation  between  columns  as  part  of  the  background  design.  The  table  has  a 
vertical  scrollbar  on  the  right  side  of  the  furthest  right  column  for  moving  the  viewable  area. 

4.2. 3.5  Button  Conventions 

(Ref:  Para.  3.1.3.4  of  ANSI/AIAA  R-023-1995  HCISSO  and  Para.  6.1  of  the  User 

Interface  Specification  for  the  Dll,  v.3.0,  1998) 

Buttons  should  be  used  for  frequently  executed  actions  or  for  the  convenience  of  the 

operator.  The  following  paragraphs  contain  specific  implementation  conventions. 

4.2.3.5.1  Appearance 

•  Rectangular  construct  (wider  than  high  or  square). 

•  Appears  raised  (light  colored  border  [edge]  on  top  and  left  side,  dark  gray  shadow  on  bottom 
and  right  side). 

•  Contains  a  label  or  graphic  centered  in  the  button. 

•  Groups  of  similar  buttons  are  the  same  size.  Exceptions  are  possible  when  label  sizes  vary 
widely. 

•  Columns  of  buttons  are  aligned  on  the  left  side.  Rows  of  buttons  are  aligned  on  bottom. 

•  Black  text  is  used  for  on-line  systems. 
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•  Grayed-out  text  is  used  for  off-line  systems. 

•  Status  can  be  indicated  through  use  of  borders,  fill,  or  combinations  of  both  as  well  as  the  use 
of  icons,  see  Table  3.2,  Color  Usage  Definitions. 

4.2.3.5.2  Behavior 

•  Activated  by  a  left  mouse  click  or  keyboard  enter/return  action. 

•  When  selected,  has  visual  indication  of  activation. 

•  Secondary  or  alternative  access  to  button  functionality  can  be  provided  through  a  menu  bar. 

4.2. 3.5.3  Push  Button  Conventions 

•  Contains  textual,  graphic,  or  icon  label  centered  in  button. 

•  Activates  frequently  executed  actions,  commands,  or  routings  (opening  another  window). 

4.2. 3.5.4  Status  Buttons 

•  Indicate  status  of  a  component  or  sub-system  through  appropriate  color  coding  (see  Tables 
3.1,  Color  Definitions,  and  3.2,  Color  Usage  Definitions)  or  use  of  status  icon. 

•  Provide  hierarchical  access  to  additional  lower  level  information  when  selected. 

4.2. 3.5.5  Common  Action  Buttons 

(Ref:  Para.  6.2.4. 1  of  OSF  Motif  Style  Guide,  v.1.2  and  Appendix  C  of  the  User  Interface 
Specifications  for  the  Dll,  v.3.0,  1998) 
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Table  4.1.  Common  Button  Actions 


Button  Label 

Action  Definition 

Add 

An  ‘Add’  push  button  is  used  to  add  a  selected  item  from  a  list  in  an  instance 
where  multiple  selections  are  possible. 

Apply 

Executes  the  action  or  current  changes,  but  leaves  the  window  open  (see 

OK). 

Back 

Recalls  the  window  that  invoked  the  current  window  and  moves  the  input- 
focus  to  that  window  (i.e.,  navigate  back  to  the  previous  window). 

Cancel 

Closes  the  dialog  or  current  window  without  implementing,  saving,  or 
executing  any  changes  or  selected  actions.  Does  not  close  any  associated 
windows.  Do  not  use  Cancel  to  close  windows  in  which  action  has  been 
initiated  and  cannot  be  terminated.  Cancel  is  often  used  on  transitory  dialog 
boxes. 

Clear 

Removes  data  from  the  selected  portion  of  an  input  field  and  does  not 
compress  the  remaining  space  occupied  by  the  cleared  data. 

Clear  All 

Removes  data  from  all  input  fields  and  does  not  compress  the  remaining 
space. 

Close 

Closes  current  window  without  performing  any  of  the  actions  specified  by 
the  components  in  the  window.  If  items  in  the  window  have  been  modified 
since  the  last  save  action,  a  dialog  confirming  the  Close  action  is  displayed 
(see  Exit). 

Delete 

Removes  the  selected  data  and  compresses  the  associated  spaces. 

Edit 

Provides  a  pop-up  menu  or  edit  control  window  with  edit  options  such  as 
cut,  copy,  move,  paste,  and  delete. 

Exit 

Closes  all  windows  in  an  application  and  ends  processing  by  the  application. 

Is  located  in  main  application  window  (use  close  for  secondary  windows). 
Unsaved  changes  will  be  lost,  a  dialog  confirming  the  Exit  action  is 
displayed. 

Expand 

Invokes  another  window,  which  contains  more  detail. 

Forward 

Invokes  the  next  window  in  a  sequence  of  windows  used  to  accomplish  a 
task  and  changes  input -focus  to  the  new  (next)  window  (i.e.,  navigate  from 
current  window  to  next  window  in  task  sequence). 

Help 

Activates  the  help  feature  when  additional  information  is  available  (See 

Para.  5,  Help). 

No 

Performs  action  of  answering  “No”  and  closing  dialog  box  when  used  with  a 
dialog  box.  Used  in  combination  with  “Yes”. 

OK 

Applies  any  changes,  performs  related  actions,  and  closes  the  window/dialog 
box  (see  Apply). 

Pause 

Causes  the  task  in  progress  to  be  paused.  Used  in  combination  with  a 

Resume  button. 

Reset 

Removes  any  changes  or  actions  that  have  not  been  applied.  Window/dialog 
box  reverts  to  display  of  previous  state  with  the  initial  values  or  the  values 
the  last  time  changes  were  applied.  Does  not  close  the  window/dialog  box. 
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Button  Label 

Action  Definition 

Resume 

Causes  previously  paused  task  to  resume.  Used  in  combination  with  a  Pause 
button. 

Retry 

Causes  the  task  in  progress  to  be  paused  and  re-executed.  This  action  is 
commonly  found  in  message  dialog  boxes  that  report  an  error. 

Save 

Writes  changes  to  a  data  file  or  storage  device,  but  leaves  the  window  open. 

If  previously  saved  information  will  be  overwritten,  a  confirmation  dialog 
box  is  necessary.  If  alternative  locations  for  saving  the  data  are  available,  a 
dialog  box  that  enables  the  user  to  select  the  location  and/or  filename  will  be 
presented. 

Submit 

Sends  current  states,  conditions,  or  commands  to  an  external  device  for 
further  processing. 

Yes 

Performs  action  of  answering  “Yes”  and  closing  dialog  box  when  used  with 
a  dialog  box.  Used  in  combination  with  "No”. 

4.2. 3.5.6  Button  Order 

(Ref:  Para.  9.0  Dialog  Box  of  OSF  Motif  Style  Guide,  v.1.2) 

When  more  than  one  common  button  is  used  they  are  typically  arranged  horizontally  across  a 
window  in  a  button  box  (see  Para.  4.2.2. 5. 7,  Location  of  Buttons)  and  are  presented  in  the 
following  order  from  left  to  right  (See  Para.  4.2. 3. 5. 5,  Common  Button  Actions,  for  usage 
considerations). 

•  OK  -  Close  -  Apply  -  Retry  -  Pause  -  Resume  -  Reset  -  Cancel  -  Help 

•  Yes  -  No  -  Apply  -  Retry  -  Pause  -  Resume  -  Reset  -  Cancel  -  Help 

4.2. 3.5.7  Location  of  Buttons 

The  following  are  recommended: 

•  Utilize  button  boxes.  Button  boxes  are  horizontal  groupings  of  buttons.  Buttons  are 
placed  side-by-side  across  a  window,  normally  in  one,  but  occasionally  in  two  rows. 
Buttons  in  a  button  box  are  placed  so  that  they  appear  together,  but  no  frames  or  border 
are  used  to  separate  the  button  box  from  the  rest  of  the  window. 

•  Buttons  that  act  on  the  entire  window  are  located  at  the  bottom  of  the  window  in  a  button 
box. 

•  Buttons  that  act  on  a  portion  of  a  window  are  located  in  a  button  box  within  a  frame  that 
includes  the  fields  that  are  acted  upon. 

•  Button  boxes  placed  horizontally  at  the  bottom  of  a  window  or  within  a  frame  arc  spaced 
symmetrically  across  the  width  of  the  window. 

4.2. 3.5. 8  Cascade  Button  Conventions 

•  Used  to  initiate  selection  of  an  option  from  a  menu  list  box. 

•  Contains  a  textual  label  centered  in  button. 


•  Contains  an  arrow  graphic  that  points  the  direction  the  menu  list  box  is  to  be  posted. 
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•  When  activated  (depressed,  selected),  it  opens  a  pull-down  menu. 

4.2. 3.5.9  Option  Button  Conventions 

(Ref:  Para.  6.1.1  and  6.14  of  the  User  Interface  Specification  for  the  Dll,  v.3.0,  1998) 

•  Use  to  activate  an  Option  menu  to  select  from  a  discrete  set  of  values  or  choices. 

•  Contains  text  label  and  either  an  arrow  or  horizontal  bar  graphic  on  left  side  in  the  button. 

•  The  currently  selected  option  replaces  the  text  label  in  the  button. 

•  Invokes  an  Option  menu  (see  Para.  4.2. 3. 1.6,  Option  Menu  Conventions). 

4.2.3.5.10  Toggle  Button  Conventions 

(Ref:  Para.  6.2  and  6.3  of  the  User  Interface  Specification  for  the  DII,  v.3.0,  1998) 

•  Used  to  select  options  in  an  application  by  choosing  between  two  states:  On  and  Off, 
Enabled  or  Disabled,  etc. 

•  Check  buttons  are  a  set  of  toggles  used  for  selecting  (setting)  any  number  of  options. 

•  Radio  buttons  are  a  set  of  toggles  used  for  selecting  (setting)  only  one  option  from  a 
number  of  options. 

•  Toggle  buttons  have  a  label  either  on  the  left  or  right  side  of  a  small  push  button.  Toggle 
buttons  normally  have  circle  shaped  push  button,  check  boxes  have  a  square  push  button, 
and  radio  buttons  have  either  a  diamond  or  circle  shaped  push  button. 

•  When  selected,  the  push  button  is  filled  with  a  dark  color,  such  as  a  dark  gray  or  black. 
An  optional  implementation  used  with  check  boxes  is  for  selected  options  to  be  filled 
with  a  black  check  mark. 

•  When  not  selected,  the  graphic  fill  in  the  push  buttons  is  the  same  color  as  the  window 
background. 
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4.2.3.5.11  Spin  Button  Conventions 

(Ref:  Para.  6.13  of  the  User  Interface  Specification  for  the  Dll,  v.3.0,  1998) 

•  Used  to  select  from  a  discrete  set  of  ordered  values. 

•  Single  line  of  text  with  up-and-down-pointing  arrows  (small  push  buttons)  on  the  right 
side  of  the  text  field. 

•  Selecting  one  of  the  arrow  buttons  changes  the  value  displayed  in  the  text  field  to  the  next 
discrete  value  of  the  ordered  set. 

•  Values  can  be  entered  directly  into  the  text  field.  This  allows  the  set  of  values  to  be  used 
for  checking  the  validity  of  the  entered  value. 

4.2. 3.6  Slider  Bar  Conventions 

(Ref:  Para.  6.15  of  the  User  Interface  Specification  for  the  Dll,  v.3.0,  1998) 

•  Use  to  select  a  value  from  a  discrete  set  of  ordered  values. 

•  Contains  either  a  horizontal  slider  or  a  vertical  slider  and  an  output  field  the  same  length 
(or  height)  above  (or  to  the  left  of)  the  slider. 

•  The  position  of  the  slider  has  an  associated  value  that  is  displayed  in  the  output  field 
immediately  above  (or  to  the  left  of)  the  slider  current  position. 

4.2. 3.7  Moving  Selected  Material  Between  Lists 

Multiple  methods  are  available  from  moving  selected  material  from  one  list  to  another. 

•  Drag  and  drop. 

•  Pick-and-put  buttons  -  buttons  with  labels  Add,  Add  All,  Remove,  and  Remove  All. 

•  Pick-and-put  directional  arrows  -  buttons  with  directional  arrows.  Another  optional 
implementation  uses  positional  pick-and-put  buttons  for  repositioning  items  in  the 
destination  list. 

4.2.3.7.1  Drag  and  Drop 

This  is  a  method  of  moving  data  on  a  display  or  between  displays.  A  user  ‘clicks’  on  an  item  and 

while  continuing  to  depress  the  left  mouse  button,  the  item  is  ‘dragged,’  moving  the  mouse,  to  a 

new  location  on  the  same  display  or  another  display.  The  user  then  ‘drops,’  releases  the  mouse 

button,  to  complete  the  item  movement. 

4.2. 3.7.2  Pick-and-Put  Button  Conventions 

(Ref:  Para.  9.1.5  of  the  User  Interface  Specification  for  the  DII,  v.3.0,  1998) 

•  At  least  two  list  boxes  are  placed  either  side-by-side  or  one  on  top  of  the  other. 

•  One  of  the  list  boxes  is  designated  as  the  destination  and  the  other  list  box(es)  are  the 
source. 
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•  Items  selected  in  the  destination  list  box  and  moved  to  a  source  are  removed  from  the 
destination. 

•  Movement  of  selected  material  is  accomplished  with  either  pick-and-put  buttons  or  pick- 
and-put  directional  arrows. 

•  Items  selected  in  a  source  list  box  and  moved  to  the  destination  remain  available  in  the 
source.  An  optional  implementation  would  also  remove  moved  items  from  the  source  list 
box(es). 

4.2.3.8  Tabbed  Pages 

(Ref:  Para.  6.7  of  the  User  Interface  Specifications  for  the  DII,  v.  3.0,  1998) 

•  Use  to  decrease  navigation  movements  when  changing  between  related  or  similar 
windows. 

•  Use  as  a  tab  button  to  select  different  windows  or  portions  of  windows. 

•  Tab  button  when  selected  has  no  bottom  border.  It  appears  to  be  connected  to  a  portion  of 
the  currently  displayed  window. 

•  Each  tab  button  has  an  associated  portion  of  window,  that  when  selected  overlays  the 
portions  of  windows  associated  with  the  other  tab  buttons. 

•  A  set  of  tabbed  pages  appear  similar  to  a  set  of  file  folders  in  a  drawer  with  tab  labels. 

•  Normally  tab  buttons  are  placed  beside  other  tab  buttons  (in  a  horizontal  line). 

•  Each  tab  button  has  an  associated  partial  window. 

•  When  a  tab  button  is  selected  the  associated  partial  window  replaces  that  current  portion 
of  the  window. 

4.2. 3. 9  Scroll  Bars 

(Ref:  Para.  6.4  of  the  User  Interface  Specification  for  the  DII,  v.3.0,  1998) 

•  Controls  for  moving  the  viewable  area  of  a  component  in  the  vertical  and/or  horizontal 
direction. 

•  Are  added  to  multiple  line  input  fields,  output  fields,  menu  list  boxes,  etc.,  when  the 
component  size  exceeds  the  viewable  area. 

•  Consists  of  a  slider  moving  within  a  trough  region  that  indicates  the  full  size  of  the 
component. 

•  Movement  of  the  slider  is  accomplished  with  arrow  graphics  on  either  end  of  the  trough 
region  and  by  moving  the  slider  with  the  mouse. 

•  For  vertical  movement,  the  scroll  bar  should  be  located  on  the  right  side  of  the  scrollable 
material. 
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For  horizontal  movement,  if  needed,  the  scroll  bar  should  be  on  the  bottom  of  the 
scrollable  material. 


•  The  position  of  the  slider  represents  the  position  of  the  viewable  information  relative  to 
the  size  of  the  component. 

4.2.3.10  Gauges  and  Dials 

(Ref:  Para.  6.15.1  and  12.2  of  the  User  Interface  Specification  for  the  Dll,  v.3,  1998) 

•  Use  to  indicate  processing  or  parameter  status.  Particularly  useful  when  the  direction  of 
change  in  a  value  is  more  important  than  the  exact  value. 

•  Gauges  contain  a  trough  region  that  fills  dynamically  to  indicate  the  amount  of 
processing. 

•  Dials  contain  a  pointer  used  to  indicate  the  current  value. 

•  Gauges  and  dials  can  be  circular,  horizontal,  or  vertical. 

•  Has  an  optional  label  with  black  text  showing  the  current  value  or  the  amount  of  fill. 

•  Out-of-limits  (warning  and  critical)  range  markings  are  usually  color  coded.  Out-of -limits 
areas  of  filled  color  coding  should  only  be  visible  when  the  system  is  in  an  out-of-limits 
state. 

4.2.3.11  Sorting  Lists 

•  Sorted  lists  can  be  in  ascending  or  descending  order. 

•  Multiple  fields  and/or  parameters  can  be  sorted  simultaneously.  A  hierarchy  of  priority  is 
selected  when  multiple  fields  or  parameters  are  used. 

•  Columns  can  be  sorted  by  selecting  the  column  heading. 

•  Option  menus  or  check  buttons  can  also  be  used  to  select  the  fields  or  parameters  for 
sorting. 

4.2.3.12  Use  of  Icons/Symbology 
4.2.3.12.1  Definition 

(Ref:  Para.  3.2.1.6.5  of  ANSI/AIAA  R-023-1995  HCISSO). 

An  icon  is  a  low  fidelity  pictorial  symbol  on  the  display  window  that  can  be  used  to  activate  an 
action,  set  of  actions  (e.g.,  a  process),  or  to  represent  a  collapsed  application  task  window.  An 
icon  usually  occupies  less  than  one  square  inch  in  area.  Icons  can  be  used  to  represent  a  window 
in  a  collapsed  state  to  save  room  or  to  unclutter  the  workspace.  Window  contents  are  not  visible 
in  an  icon.  Application  window  icons  are  provided  by  the  application  when  the  operator  clicks  on 
a  designated  spot  on  the  open  window.  Each  type  of  window  that  can  be  iconfied  has  a  unique 
icon  to  distinguish  it  from  other  types  of  windows.  Icons  usually  have  a  label  at  the  bottom  of  the 
icon. 
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4.2.3.12.2  Window  Icons 


When  a  window  is  made  into  an  icon,  a  descriptive  (meaningful)  label  that  identifies  the  window 
is  attached.  Unless  specified  in  Para.  6,  Domain  Specific  Conventions,  all  windows  can  be  made 
into  icons.  Note  that  some  domain  specific  operations  (i.e.,  critical  and  real  time  operations) 
preclude  making  windows  into  icons.  However,  the  header  zone,  status  zone,  and  toolbar  cannot 
be  made  into  an  icon. 

4.2.3.12.3  Hierarchical  Icons 

•  Used  to  access  more  information  (typically  invokes  another  window)  on  the  subsystem  or 
component  described  by  the  icon. 

•  Appears  as  a  graphic  with  a  label  centered  under  the  icon. 

•  Can  indicate  status  using  color  coding,  see  Table  3.2,  Color  Usage  Definitions. 

4.2.3.12.4.  Status  Icon 

•  An  icon  used  to  indicate  status. 

•  Cannot  be  selected  to  invoke  any  actions. 

•  Typically  placed  beside,  and  associated  with,  an  output  field  or  button. 

4.2.3.13.  Graphical  Diagrams 

•  Schematics,  block  diagrams,  flow  charts,  and  wiring  diagrams  can  be  displayed  as  a 
portion  of  a  window  or  as  the  entire  window. 

•  Static  diagrams  are  displays  that  do  not  contain  any  status  information  or  the  ability  to 
access  more  information  on  particular  components. 

•  Dynamic  diagrams  are  displays  that  do  provide  real  time  status  information  on  some  or 
all  of  the  components  in  the  display. 

•  Interactive  diagrams  are  displays  that  provide  real  time  status  information  and  the  ability 
to  access  more  detailed  information  on  particular'  components. 
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5.  Help 

(Ref:  Para.  3.4.  of  ANSI/AIAA  R-023-1995  HCISSO  and  Para.  11.0  of  User  Interface  Specifications 
for  the  Dll,  v.2.0) 

Note:  The  degree  to  which  a  program  employs  the  Help  conventions  must  be  weighed  between  the 
system  concept  of  operations  and  the  funding.  Some  of  the  conventions  are  not  part  of  existing  COTS 
applications  and  require  development  and  integration  into  the  system. 

The  Help  conventions  provide  access  to  multilevel  on-line  guidance  using  prompts,  advisory 
messages,  and  so  forth.  Help  may  include  system  information  (e.g.,  navigation  help)  and/or  task- 
oriented  information  (e.g.,  step  and  process  help).  Help  is  not  meant  to  tutor  operators  but  instead  is 
meant  to  assist  them  in  recalling  information  to  perform  the  specific  task  at  hand.  Help  provides 
procedural  aids,  provides  the  ability  to  recover  from  errors,  and  provides  advice  without  requiring  the 
user  to  exit  the  application. 

Context-sensitive  on-line  documentation  help,  when  used,  provides  information  that  considers  the 
current  environment,  interrelated  conditions,  occurrences  of  events,  and  other  factors  that  exist  which 
affect  the  current  operation.  Context-sensitive  help,  when  used,  describes  the  purpose  of  the  item  or 
procedure,  and  the  expected  operator  interaction  with  the  item  or  procedure. 

5.1  Methods  of  Receiving  Help 

•  <F1>  function  key  or  the  <Help>  button. 

•  Shift  <F1>  or  Shift  <Help>  provides  context-sensitive  help. 

•  The  pop-up  menu  from  a  right  mouse  button  click. 

•  Help  push  button. 

•  If  a  menu  bar  is  used,  place  Help  on  the  right  end. 

•  Positioning  the  cursor  over  items  on  the  menu  bar,  push  buttons,  or  acronyms  for  item 
description. 

5.2  Placement  of  Help 

•  Position  a  Help  window  or  bubble  (pop-up  area  with  a  lighter  color  background  than  the 
window  background)  so  as  not  to  obscure  the  object(s)  it  is  describing. 

•  Initial  placement  covers  the  least  amount  of  information  in  the  active  application. 

•  Place  a  Help  window  or  bubble  (in  descending  order  of  preference)  to  the  right,  left,  above,  or 
below  the  content  for  which  help  was  requested. 

•  Help  windows  are  moveable,  resizeable,  and  modeless  (allowing  interaction  with  the 
secondary  window  and  all  other  windows). 
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5.3  Contents  of  Window  Specific  Help 

•  Is  accessible  from  a  window. 

•  Contains  a  purpose  statement  that  describes  the  task(s)  that  the  users  perform  in  the  window. 

•  Describes  tasks  as  they  relate  to  the  functionality  provided  by  the  application  and  from  an 
operational  perspective. 

•  Text  is  presented  in  mixed  case,  with  capitalization,  bold,  or  highlight  to  emphasize 
significant  information. 

•  Presented  items  can  be  in  bulleted  form. 

•  Items  can  be  sequentially  numbered  steps. 

•  Use  graphics  to  supplement  the  text  where  appropriate. 

•  Examples  may  be  used  to  explain  complex  ideas. 

•  Present  step-by-step  explanation  of  how  users  execute  the  task(s)  for  which  Help  was 
requested. 

5.4  System  or  Application-Level  Help 

•  Is  accessible  from  the  primary  (parent)  application  window,  normally  from  the  Help  menu. 

•  Provides  on-line  technical  support  documentation  such  as:  electronic  Orbital  Operations 
Handbook  (OOH),  vehicle  schematics,  photos,  definitions  of  options,  system  capabilities, 
procedures,  abbreviations,  acronyms  and  ranges  of  values  that  should  be  displayed.  Note: 
Much  of  this  on-line  documentation  is  also  accessible  from  window  specific  help. 

•  Provides  overview  of  tasks  performed  in  application. 

•  Provides  access  to  more  detail  on  particular  tasks  and  steps. 

•  Wizards  are  a  common  method  for  providing  detailed  task  description  information,  including 
step-by-step  instructions. 

5.5  Context  Sensitive  Help 

•  When  invoked  (Shift  <F1>  or  help  menu  selection),  changes  the  pointer  to  a  “help”  shape. 
User  moves  pointer  to  a  component  (object)  and  left  clicks  mouse  to  display  information 
about  that  component. 

•  Describes  the  nature  of  and  how  to  use  a  particular  control  (check  button,  radio  button,  slider 
bar,  data  entry  field,  etc.),  component,  or  current  transaction. 
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5.6 


Help  Menu  Options 

•  Context  Sensitive  Help  -  Alternative  way  to  invoke  context  sensitive  help. 

•  Index -of  all  topics  with  categories  such  as;  functions,  commands,  keys,  etc.  All  indexes 
should  be  alphabetical  and  provide  quick  search  capabilities.  Note:  Index  categories  can  also 
be  separate  items  in  Help  menu. 

•  On  Help  -  Provides  information  on  how  to  use  application  help  facility. 

•  On  Window  -  Specific  to  current  window. 

•  Tutorial  (optional). 

•  Version  -  Provide  name  and  version  of  application. 

5.7  Acronyms  and  Data  Items 

•  When  the  cursor  is  placed  over  an  acronym,  the  expanded  label  (text)  describing  the  acronym 
is  displayed  in  a  pop-up  area  (bubble). 

•  Clicking  on  a  data  item  to  highlight  the  item  displays  the  definition  or  information  about  the 
selected  item. 
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6.  Domain  Specific  Conventions 


6.1  Satellite  Contact  Operations  Conventions 

6.1.1  Description 

Contact  Operations  consist  of  satellite  support  activities  to  include:  execution  of  individual  satellite 
contacts,  configuration/deconfiguration  of  resources,  execution  of  the  satellite  support  plans,  in¬ 
procedure  anomaly  resolution,  status  reporting,  and  coordination  with  external  agencies  as  required. 

One  of  the  products  reviewed  for  this  domain  was  the  LORAL  System  90,  used  in  5  SOPS  as  a 
Mission  Unique  Equipment  (MUE)  telemetry  processor.  The  specific  items  reviewed  on  this  system 
were  the  telemetry  windows,  graphics,  window  navigation,  and  screen  layout.  The  GPS  processing 
system  telemetry  windows  were  also  reviewed.  Some  of  these  windows  were  recreated  in  the  UIM/X 
tool  to  exhibit  how  these  windows  match  or  can  be  altered  to  meet  conventions.  The  following  is  a  list 
of  the  windows  that  were  recreated: 


•  Attitude 

•  Propulsion 

•  Satellite  Processing  Unit 

6.1.2  Screen  Layout 

Described  below  is  screen  layout  information  regarding  arrangement  of  windows  and  navigation, 
rules  on  overlapping  windows,  as  well  as  definitions  and  handling  criteria  for  critical  information. 

6.1. 2.1  Arrangement  of  Windows  and  Navigation 

Accelerator  and  functions  keys  are  available  for  frequently  used  functions.  Examples  of  functions 
requiring  shortcut  keys  are  in  Table  6.1,  Contact  Operations  Default  Shortcut  Key  Definitions. 


Table  6.1.  Contact  Operations  Default  Shortcut  Key  Definitions 


Shortcut 

Key 

Function  /  Action 

F2 

Network  Status 

F3 

SOC  Equipment  Status 

F4 

Contact  Status 

F5 

Configure  Front  End 

F6 

Configure  KGs 

The  SCREENS  option  on  a  window  menu  is  a  specific  implementation  of  a  list  of  windows  that  the 
user  can  activate  quickly.  Function  keys,  accelerator  keys,  and  push  buttons  are  other  methods  that 
allow  director  access  to  windows  and  functions.  Direct  access  to  windows  and  functions  is  useful  to 
Contact  Operations  and  allows  the  operator  to  quickly  obtain  Contact  Operations  functions,  to  switch 
automation  levels,  and  to  monitor  all  facets  of  the  contact. 
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6. 1.2.2  Rules  on  Overlapping  Windows 

Non-overlapping  or  tiled  convention  for  window  placement  is  recommended  in  the  Contact 
Operations  domain  for  the  following  reasons: 

•  Contact  Operations  is  a  real-time  domain  that  frequently  requires  more  than  one  window  to 
be  opened  for  simultaneous  viewing. 

•  Timeliness  of  operator  actions  requires  that  operator  window  manipulation  or  placement  be 
reduced  or  eliminated. 

•  Operator  screen  management  and  extra  steps  are  typical  of  overlapping  or  cascaded  windows. 

This  design  convention  does  allow  for  dialog  and  feedback  windows  to  appeal-  on  top  of  (or 
overlapping)  the  current  window  when  an  operator  action  is  required  prior  to  leaving  the  window  or 
continuing  to  the  next  step. 

6.1 .2.3  Definition  and  Handling  of  Critical  Information 

The  critical  data  in  the  Contact  Operations  domain  can  include  anything  that  prevents  the  mission 
from  being  accomplished,  or  which  poses  a  danger  to  personnel.  Some  examples  are:  satellite 
anomalies,  ground  anomalies,  communication  outages,  degradations  or  failures  of  almost  anything 
related  to  contact  operations  mission,  fire  alarms,  emergency  messages,  and  so  forth.  As  described  in 
Para.  3. 1.3.2,  Alert  Area,  critical  alert  information  is  color-coded,  accompanied  by  an  audible 
notification,  appears  in  a  dialog  window,  or  appears  in  the  alert  area  as  a  message.  Operator 
notification  of  critical  alert  data  requires  operator  action/acknowledgment  such  as  a  click  on  a  button 
via  a  dialog  window  or  an  alarm  acknowledgment. 

There  are  multiple  functions  that  can  be  employed  in  identifying  critical  data  in  a  Contact  Operations 
window.  Commands,  directives  and  functions  can  utilize  the  color-coding  convention  on  the  text  field 
that  displays  the  results  of  these  actions.  Limits  can  be  placed  on  parameters  that  have  a  range  of 
acceptable  values.  The  color  conventions  of  yellow  for  warning  state  and  red  for  alarmed  state  are 
used  to  identify  the  values  that  are  not  in  the  acceptable  range  of  values.  To  allow  for  high-level  data 
monitoring,  a  hierarchical  status  notification  can  be  employed.  A  high  level  window  uses  the  color 
convention  on  a  button  to  convey  that  a  subsystem  or  a  portion  of  the  subsystem  is  reporting  degraded 
or  critical  telemetry  data.  The  user  can  click  on  the  button  to  obtain  more  detailed  information  on  the 
subsystem  and  locate  the  degraded  or  critical  telemetry  data. 

6.1.3  Header  Zone 

The  header  zone  for  Contact  Operations  utilizes  the  conventions  as  described  in  Para  3.1.2,  Header 
Zone.  The  items  that  are  most  pertinent  to  this  domain  are  the  security  classification  and  user 
identification,  for  obvious  security  reasons,  and  mode  indicator,  for  operator  situational  awareness. 

6.1.4  Status  Zone 

The  status  zone  contains  the  status  area  and  the  alert  area.  Both  areas  display  data  that  is  essential  for 
the  operator  to  keep  in  view  at  all  times.  For  Contact  Operations,  this  kind  of  data  may  include:  a 
current  schedule  of  supports,  single  contact  status,  multiple  contact  status,  system  status,  external 
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equipment  status,  remote  station  status,  and  network  status.  The  section  below  describes  Contact 
Operations  specific  status  area  and  alert  area  conventions. 

6.1. 4.1  Status  Area 

The  following  components  are  examples  of  the  content  that  may  be  displayed  in  this  area. 

6.1. 4.1.1  Activities  Schedule 

Alternative  1-  The  Activities  Schedule  includes  a  view  of  current  and  upcoming  contacts  on  the 
schedule.  The  operator  can  start  a  contact  by  double-clicking  on  the  contact  line  in  the  schedule.  The 
schedule  can  be  sorted  by  the  column  titles.  The  sorting  feature  is  accomplished  by  placing  the 
column  title  on  a  button.  Activation  of  the  button  sorts  the  schedule  by  the  selected  column  title  in 
ascending  order.  An  additional  behavior  of  the  button  is  a  toggle  feature,  which  allows  the  sort  to 
switch  between  ascending  and  descending  order. 

Alternative  2  -  A  view  of  the  scheduled  contact  events  is  in  a  timeline  format.  The  timeline  displays 
times  on  one  axis  and  the  total  number  of  possible  contacts  on  the  opposing  axis.  The  length  of  the 
box  representing  the  contact  depicts  contact  duration.  The  vehicle  Interange  Operations  Number 
(IRON)  labels  the  box.  The  user  could  define  colors  to  further  define  contact  attributes  such  as 
minimum  manning  level  or  type  of  contact  (state  of  health,  tracking,  or  maneuver). 

6.1. 4.1. 2  Resource/Activities  Status 

Resource/ Activities  Status  includes  a  view  of  contact  resources  for  the  operations  complex. 
Alternatives  include: 

Alternative  1  -  Shows  all  active  contacts  (up  to  6)  for  the  complex.  The  active  contacts  are  listed  by 
satellite  identifier  and  the  graphical  status  display  changes  per  selected  satellite. 

Alternative  2  -  Shows  the  status  of  one  current  contact.  A  graphical  representation  of  the  contact 
resources  displays  the  status  of  the  contact. 

6. 1.4.2  Alert  and  Message  Area 

The  alert  and  message  area  follows  conventions  described  in  Para.  3. 1.3.2,  Alert  Area.  Table  6.2 
provides  examples  of  Alarms  (A),  Warnings  (W),  and  Events  (E).  Note  that  the  source  can  be  an 
IRON  number,  ground  element,  or  external  location. 
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Table  6.2.  Contact  Operations  Alarms,  Warnings,  and  Event  Examples 


Criticality 

Date/Time 

Source 

Text 

A 

149/00:23:00 

1234 

Loss  of  data 

A 

149/00:20:00 

1234 

Loss  of  Sync 

W 

149/00:19:00 

1234 

APA  buffer  below  limit 

W 

149/00:17:00 

1234 

Inconsistent  time  from  source 

E 

149/00:14:00 

1234 

Data  acquired 

E 

149/00:13:00 

1234 

Antenna  is  radiating 

6.1.5  Toolbar 

The  operations  associated  with  Contact  Operations  are  typically  time  critical  operations.  The  toolbar 
can  be  placed  either  above  or  below  the  status  zone  or  at  the  bottom  of  the  screen.  Care  must  be  taken 
to  choose  a  location  that  avoids  a  situation  in  which  critical  data  is  covered  by  the  toolbar  menus 
when  open.  The  toolbar  pull  down  menu  selection  would  appear  highlighted  if  the  pull  down  were 
accessed  again.  The  following  provides  the  recommended  content  of  the  toolbar: 

•  SOC  Control  Monitor  -  Internal  resource  configuration,  system  control,  initiate  and  terminate 
contacts,  logoff 

•  Commanding  -  Commanding  windows,  contact  plan  (loading,  viewing) 

•  Telemetry  -  Telemetry  launch  points,  telemetry  limit  control  point 

•  Pre-Pass  -  Pre-Pass  tests,  brief,  and  ARTS  monitoring 

•  Playback  -  Telemetry  playback,  initiation 

•  Print  -  Prints  of  window  or  specific  screens 

•  Utilities  -  Terminal  access,  calculator 

•  Help  -  System,  vehicle  and  pass  plan  help 

6.1.6  Contact  Operation  Specific  Conventions 
Listed  below  are  Contact  Operation  specific  conventions: 

•  Color  status  indicators  are  used  in  resource  status  windows  to  provide  a  general  view  of 
equipment  pieces. 

•  Only  configurations  defined  in  a  vehicle  database  can  be  selected. 

•  Contact  progress  is  conveyed  by  moving  data  between  upcoming  and  history  lists.  Status  of 
the  item  is  also  displayed  in  the  list. 
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•  System  generated  default  input  is  based  on  previous  user  input.  The  user  may  still  edit  the 
selection  but  the  system  utilizes  the  previous  user  input  to  minimize  user  inputs  where 
applicable. 

•  The  list  filter  option  allows  a  list  to  be  sorted  by  specifying  the  main  criteria  of  the  sort  which 
is  selected  with  toggle  buttons. 

•  The  sort  list  input  allows  for  the  user  to  type  the  sorting  criteria  in  an  input  field.  Once  the 
criterion  is  completed,  the  system  performs  the  sort  upon  a  button  selection. 

•  Dials,  meters,  and  gauges  are  different  ways  to  display  data.  These  graphics  are  used  to 
emulate  mechanical  devices. 

•  The  following  are  buttons  with  specific  titles  and  functions  used  only  in  the  Contact 
Operations  domain: 

-  Monitor  -  Allows  a  user  to  view  the  contact  data.  Control  of  the  contact  is  not  available 
from  this  function. 

-  Take  Control  -  Allows  a  user  to  obtain  control  of  a  current  contact.  The  previous  user 
releases  control  to  the  new  user,  which  is  the  user  selecting  the  ‘Take  Control’  button. 

-  Begin  Contact  -  Allows  a  user  to  begin  a  contact  that  does  not  have  an  SSP,  pass  plan, 
and  has  been  configured  manually. 

-  Next  Rev  -  Allows  the  user  to  use  the  next  tracking  station  visibility  in  the  upcoming 
revolution  of  the  predicted  vehicle  orbit  data.  The  input  fields  are  populated  with  the  data 
from  the  predicted  vehicle  orbit  data. 

-  Test  and  configuration  buttons  perform  pre-pass  tests  and  equipment  configurations  for 
vehicle  contacts. 

-  Send  -  Transmits  commands  and  directives  from  the  ground  systems  through  the  antenna 
and  to  the  vehicle. 

-  Abort  -  Discontinues  the  execution  of  the  current  transmission  to  the  vehicle  and/or 
execution  of  the  pass  plan. 

-  Apply  Offset  -  Executes  a  directive  to  sync  the  antenna  pointing  angles  to  a  certain  time 
offset.  The  Antenna  Off  set  input  field  accepts  the  time  offset  from  the  user. 

6.1.7  Contact  Operation  Windows 

The  following  sections  provide  descriptions  of  the  Contact  Operation  Windows. 

6.1 .7.1  SOC  Resources  Window 

The  SOC  Resources  window  allows  for  an  overview  of  the  resources  within  the  operations  complex. 
This  window  utilizes  the  color  status  indicators.  Since  each  complex  has  different  types  and  numbers 
of  equipment  pieces,  arrangement  of  equipment  in  this  window  varies  between  each  SOC.  The  SOC 
Resources  window  gives  a  very  general  view  of  equipment  pieces  and  how  they  are  displayed.  This 
window  has  a  one  line  title  bar  that  is  used  on  most  contact  operations  windows.  To  exit  this  window, 
the  user  employs  the  window  controls  (Para.  4.2.1). 


45 


6.1. 7.2 


Network  OPSCAP  Status  Window 


Network  status  for  external  resources  can  be  found  on  the  Network  OPSCAP  Status  window.  This 
window  utilizes  antenna  icons  on  buttons  to  portray  the  status  of  an  antenna  site  with  color  status 
indicators.  Status  buttons  allow  a  user  access  to  more  information  on  the  site.  To  obtain  more 
information,  a  button  activation  initiates  a  window  that  contains  detailed  information  on  the  selected 
piece  of  equipment.  The  Network  OPSCAP  status  window  uses  buttons  without  icons  to  depict  other 
resources  such  as  the  Defense  Communications  System/Satellite  Control  Facility  Interface  System 
(DS1S).  To  exit  this  window,  the  user  employs  the  window  controls  (Para.  4.2.1). 

6. 1.7.3  Internal  Resources  Configuration  Window 

Configuration  of  the  internal  resources  is  accomplished  on  the  Internal  Resources  Configuration 
window.  This  window  is  available  for  situations  when  the  automated  SSP  is  not  possible  or  feasible. 
The  window  depicts  the  recommended  columnar  format.  The  window  uses  option  menus  for 
configuration  choices.  Only  configurations  defined  in  a  vehicle  database  can  be  selected.  Apply  and 
Cancel  buttons  are  used  to  execute  changes  made  and  to  exit  the  window.  This  window  is  specific  to 
an  operations  complex  specific  environment.  All  configurable  resources  may  be  displayed  here.  This 
window  is  just  an  example  of  how  to  display  such  items.  Most  operations  complexes  have  more  items 
to  configure.  Toggle  buttons  are  used  for  selecting  yes/no  options. 

6.1. 7.4  Select  Contacts  Window 

The  Select  Contacts  window  allows  the  user  to  review  the  scheduled  contacts  for  the  complex.  The 
user  can  select  to  start  a  scheduled  contact,  monitor  or  take  control  of  a  contact,  or  start  a  contact  that 
is  not  scheduled.  Pressing  the  appropriate  button  activates  these  functions.  Stalling  or  joining  a 
contact  is  accomplished  by  selecting  a  contact  from  the  scrollable  list  and  selecting  the  appropriate 
button.  The  operations  concept  must  be  considered  when  specifying  the  behavior  of  actions  such  as 
taking  control  of  a  contact.  Possible  implementations  may  include  pop-up  windows  for  the  outgoing 
and  incoming  users  or  a  pop-up  window  for  flight  commander  approval.  Graying  out  is  recommended 
for  unauthorized  user  functions.  The  user  may  sort  the  scheduled  contacts  by  clicking  on  the  column 
heading,  which  is  also  a  sort  label,  of  the  contact  list.  The  sort  label  functions  as  a  toggle  button.  The 
first  click  sorts  the  list  by  the  selected  column  in  ascending  order  and  the  second  click  on  the  column 
sorts  the  list  in  descending  order.  The  help  function  can  be  accessed  by  pressing  the  Help  button.  The 
items  displayed  in  the  contact  list  are  definable  by  the  operations  complex.  Complete  contacts  can  be 
selected  for  “no  display,”  can  be  displayed  in  a  specified  color,  or  can  be  shown  as  “grayed  out”  as 
defined  by  the  operations  complex.  Active  contacts  can  be  shown  as  a  specific  color  or  highlighted. 
An  alternative  view  is  to  present  the  contact  list  in  a  timeline  format.  The  window  control  convention 
is  used  to  exit  this  window  if  the  user  does  not  start  or  join  a  contact.  Starting  or  joining  a  contact 
deactivates  the  Select  Contacts  window  and  activates  a  contact  or  telemetry  window  depending  on  the 
contact  type  and  pass  plan. 

6.1 .7.5  Initiate  Non-SSP  Window 

This  window  allows  users  to  add  a  real-time  contact  to  the  schedule  using  pull  down  menus  and  input 
fields.  This  window  is  displayed  when  the  New  button  is  activated  on  the  Select  Contacts  window. 
Option  menus  are  used  to  restrict  user  selections  to  items  defined  in  the  database.  The  input  field  can 
be  populated  by  previous  user  selections.  For  example  the  ‘Next  Rev’  button  obtains  the  data  from  the 
orbit  propagation  and  populates  the  input  fields.  These  fields  also  accept  user  input.  DSIS  and 
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RTS/ARTS  configuration  defaults  are  filled  into  the  input  fields  once  the  IRON  selection  is  made. 
One  alternative  is  to  allow  for  multiple  contact  type  selections  by  placing  items  selected  from  the 
option  menu  into  a  Contact  Type  List.  The  contact  type  option  menu  is  categorized  for  better 
organization.  This  window  is  displayed  until  the  Begin  Contact  button  (which  is  available  upon 
completing  data  input)  or  the  Cancel  button  is  activated.  Either  button  deactivates  the  current  display. 
The  Begin  Contact  activates  the  Internal  Resources  Configuration  window. 

6.1. 7.6  Pre-Pass  Brief  Window 

The  Pre-Pass  Brief  window  is  an  automated,  informational  display  for  the  operator  to  use  when 
briefing  the  site  and  network  connections.  The  Pre-Pass  Brief  window  is  a  static  window  with  text 
fields  indicating  configurations  determined  by  the  SSP  or  previous  operator  selections.  To  exit  this 
window,  the  user  employs  the  window  controls  (Para.  4.2.1). 

6. 1.7.7  Pre-Pass  Test  Window 

The  Pre-Pass  Test  window  employs  push  buttons  to  launch  tests  and  text  fields  to  display  the  results. 
A  test  is  executed  by  selecting  a  button  of  the  associated  test.  The  test  results  appear  as  text  in  the 
output  field.  The  output  fields  also  have  status  indicators  of  color  to  convey  the  test  results.  The  status 
indicators  give  a  quick  visual  color  response  of  the  test  results.  The  top  of  the  window  depicts  a  one- 
line  title  bar  and  a  menu  bar.  Cancel  and  Help  buttons  are  present  to  exit  the  function  and  to  obtain 
help. 

6.1 .7.8  Contact  Summary  Window 

The  Contact  Summary  window  relies  heavily  on  an  automated  system.  The  window  is  dependent  on 
automation  because  the  SSP  is  executing  and  the  user  actions  are  limited.  The  user  actions  are  to  stop 
the  automation,  change  the  level  of  automation  to  manually  execute  the  pass  plan,  or  access  another 
window  to  edit  the  pass  plan.  This  window  gives  an  overall  picture  of  the  contact.  There  are  static 
information  pieces,  such  as  satellite  identifier,  contact  times,  purpose  (defined  by  the  SSP),  and 
timing  parameters.  The  contents  of  the  SSP  are  displayed  in  a  scrollable  list.  The  push  buttons  with 
arrows  allow  the  user  to  increase  or  decrease  the  portion  of  the  SSP  displayed,  allowing  the  user  to 
view  the  SSP  at  a  high  activity  level  or  at  the  command  level.  One  option  to  show  contact  progress  is 
to  change  the  label  on  the  action  button  to  the  left  of  a  command  or  activity.  The  example  window 
uses  the  terms  Done,  for  completed  actions,  Active,  for  the  current  action,  or  Start,  for  upcoming 
actions.  The  functionality  of  the  push  buttons  to  the  left  of  the  SSP  item  varies  depending  on  the 
system  automation  level.  The  automation  level  can  be  changed  using  an  option  menu.  The 
Commanding  push  button  activates  the  commanding  window.  The  Pause,  Resume  and  Abort  buttons 
used  on  this  window  pertain  to  the  SSP.  This  window  also  shows  an  example  of  a  two-line  title  bar. 
To  exit  this  window,  the  user  employs  the  window  controls  (Para.  4.2.1). 

6.1. 7.9  Contact  Monitor  Window 

The  Contact  Monitor  window  is  an  informational  display  that  shows  detailed  contact  connection  data. 
The  color  status  convention  could  be  added  to  this  window  to  show  an  anomalous  change  to  a 
parameter.  The  bulk  of  the  information  is  displayed  in  text  fields.  Only  one  input  field  and  two  push 
buttons  are  provided  for  operator  interaction.  The  Antenna  Offset  input  field  and  Apply  Offset  push 
button  are  utilized  only  when  an  offset  is  necessary  to  correct  the  times  associated  with  the  antenna 
pointing  angles.  The  Close  button  deactivates  the  window.  The  OK  button  is  the  preferred  method  of 
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deactivating  this  window.  Recommended  additions  to  this  window  are  the  source  of  the  contact 
timing  and  the  sync  status. 

6.1.7.10  Telemetry  Display  Windows 

Text  and  graphics  are  used  to  convey  information  about  the  vehicle  or  the  mission  on  the  telemetry 
windows.  Dials,  meters,  gauges,  lines,  and  arrows  are  used  to  make  the  windows  more  graphical. 
Graphical  color  status  indicators  and  text  fields  are  used  to  associate  telemetry  limits.  Different  views 
of  these  items  can  be  found  on  the  Communications,  Electrical  Power,  and  Thermal  Control  windows. 
The  Thermal  Control  window  utilizes  the  recommended  method  of  displaying  limits.  Lines  and 
amows  depict  the  flow  of  data  through  a  subsystem,  as  exemplified  in  Communications  and  Electrical 
Power  windows.  An  example  of  a  two-line  title  bar  is  displayed  on  the  Vehicle  Subsystem  window. 
All  of  the  telemetry  window  examples  utilize  the  window  control  convention. 

The  Attitude  and  Propulsion  windows  have  static  pictures  to  help  the  engineer  envision  the  attitude  of 
the  vehicle.  Pictures  of  satellites  can  be  used  to  depict  a  subsystem  or  equipment  placement  on  a 
satellite  or  a  satellite’s  orientation  to  the  earth.  Static  pictures  can  be  used  with  most  tools  without  any 
coding.  Dynamic  functions  such  as  orienting  the  vehicle  to  the  earth  require  a  substantial  amount  of 
coding.  Some  tools  may  not  have  widgets  defined  to  allow  for  such  functionality. 

6.1 .7.1 1  End  of  Contact  Window 

This  window  returns  resources  to  their  systems  resource  pool.  It  also  deactivates  contact  functions 
such  as  telemetry  and  contact  connections.  This  window  follows  the  same  conventions  as  the  Pre-Pass 
Test  window.  This  window  shows  a  one-line  title  bar  and  a  menu  bar.  The  window  utilizes  the  OK, 
Cancel  and  Help  conventions.  Menu  bar  functions  are  not  repeated  with  buttons.  A  link  to  the  log 
functions  is  also  accessible  on  this  window.  Color  status  indicators  can  also  be  used  on  this  window, 
such  as  those  found  on  the  Pre-Pass  Test  window. 

6.1.7.12  Commanding  Window 

The  Commanding  window  is  used  to  monitor  the  progress  of  the  commands  sent  to  the  vehicle  by  the 
pass  plan.  The  History  list  shows  the  number  of  steps  of  each  command  that  was  received  by  the 
vehicle.  An  option  for  this  list  is  to  show  the  results  of  the  command,  displaying  the  main  telemetry 
points  affected  by  the  command.  This  list  also  shows  if  the  command  has  completed  or  is  still  being 
received.  The  upcoming  command  list  shows  the  upcoming  commands  as  defined  in  the  SSP.  Future 
commands  are  editable  from  the  Commanding  -  Modify  window.  Because  the  Modify  button  is  the 
access  to  manual  commanding,  the  SSP  pauses  upon  Modify  button  selection.  There  is  also  push 
button  access  to  abort  the  current  command  as  well  as  to  activate  the  Commanding  Modify  window. 
Option  menus  are  used  to  select  the  command  mode  and  authorization.  A  text  field  is  used  to  display 
the  vehicle  command  count  and  a  text/input  field  to  display  or  change  ground  command  count.  A 
push  button  is  used  to  Send  the  next  command  to  the  vehicle  if  full  automation  has  been  discontinued. 
The  Apply  button  activates  a  Ground  Command  Count  change  and  the  Status  push  button  activates 
the  Commanding  Status  window.  Utilize  function  keys  for  access  to  the  lower  level  functions 
allowing  direct  access  to  commanding  actions  (Para.  6. 1.2.1,  Arrangement  of  Windows  and 
Navigation).  To  exit  this  window,  the  user  employs  the  window  controls  (Para.  4.2.1). 
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6.1.7.13  Commanding-Status  Window 


This  window  shows  status  of  the  hardware  used  on  the  current  contact  using  the  color  status 
indicators.  Status  buttons  labeled  with  equipment  titles  allow  the  user  to  select  more  information  on 
each  equipment  piece  by  selecting  the  applicable  button.  The  OK  button  is  used  to  exit  the  window.  A 
Close  button  is  the  preferred  method  of  exiting  this  window.  Variations  such  as  back-up  equipment 
and  alternative  connectivity  paths  could  be  incorporated  into  this  window. 

6.1 .7.1 4  Commanding-Modify  Window 

This  window  uses  radio  buttons  to  select  sorting  filters  and  check  buttons  to  select  restrictions. 
Buttons  are  used  to  activate  filter  and  sorting  capabilities.  Text  fields  allow  for  user  input  to  select  or 
search  for  certain  characteristics  of  a  command.  Input  fields  are  used  to  input  time  tags  and  display 
the  selected  command.  An  input  field  allows  for  user  input,  default  values,  and  selected  input  to 
display  in  the  same  field,  if  supported  by  the  operations  concept.  An  operations  concept  may  require 
command  selection  from  the  command  list.  The  OK,  Apply  and  Cancel  buttons  are  used  to  implement 
the  modifications  or  to  exit  the  function.  The  Apply  button  allows  the  user  to  make  multiple  changes 
without  leaving  the  Commanding  -  Modify  window. 

6.2  Satellite  Mission  Planning  Conventions 

6.2.1  Description 

Mission  Planning  is  responsible  for  all  tasks  associated  with  non-real-time  scheduling  and  preparation 
of  supports  to  meet  mission  requirements  of  a  satellite  constellation.  This  includes  keeping  track  of 
schedule-impacting,  long-term  satellite  control  network  outages,  maintaining  support  requirements 
catalogs,  preparing  long-term  support  schedules  for  a  satellite  constellation,  and  preparing  selected 
Satellite  Support  Plans. 

6.2.2  Screen  Layout 

Described  below  is  screen  layout  information  regarding  arrangement  of  windows  and  navigation, 
rules  on  overlapping  windows,  as  well  as  definitions  and  handling  criteria  for  critical  information. 

6.2.2. 1  Arrangement  of  Windows  and  Navigation 

Accelerator  and  function  shortcut  keys  are  available  for  frequently  used  functions.  Examples  of 
functions  requiring  shortcut  keys  are  in  Table  6.3,  Mission  Planning  Shortcut  Key  Definitions. 

Table  6.3.  Mission  Planning  Default  Shortcut  Key  Definitions 


Shortcut 

Key 

Function  /  Action 

Ctrl-R 

Support  Requirements 

Ctrl-S 

Schedule  Change  Requests 
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6. 2. 2. 2  Rules  on  Overlapping  Windows 

Many  screens  in  Mission  Planning  require  a  great  amount  of  screen  space  to  be  useful.  Tiling  may  be 
inappropriate  for  some  types  of  screens  such  as  schedules  and  resource  availability  forecasts,  which 
require  maximum  viewing.  Therefore,  use  cascading  screens  when  multiple  windows  need  to  be 
present  on  the  desktop. 

6.2.2. 3  Definition  and  Handling  of  Critical  Information 

Critical  information  specific  to  Mission  Planning  may  be  defined  as  any  significant  unexpected  event 
that  might  require  the  Mission  Planner  to  change  the  course  of  future  planning  or  redo  previously 
completed  planning  activities.  Critical  information  may  include,  but  is  not  limited  to,  schedule 
changes  and  mission  impacting  outages.  As  described  in  Para  3. 1.3.2,  Alert  Area,  this  type  of  critical 
information  may  be  displayed  by  color-coded  alarm  messages  in  the  Alert  Area  as  well  as  audible 
alarms.  However,  because  Mission  Planning  is  by  definition  a  non-real-time  activity,  none  of  this 
information  requires  immediate  action  and,  therefore,  is  never  presented  with  confirmation  dialog 
boxes.  Another  type  of  critical  information  is  specific  to  personnel  safety  or  security.  This  type  of 
critical  information  follows  guidance  in  3. 1.3.2  of  the  Alert  Area  section. 

6.2.3  Header  Zone 

The  header  zone  for  Mission  Planning  utilizes  the  conventions  as  described  in  Para.  3.1.2,  Header 
Zone. 

6.2.4  Status  Zone 

The  size  of  the  status  zone  should  be  designed  to  use  minimum  workspace,  allowing  more  work  zone 
area  which  is  very  important  to  the  majority  of  the  tasks  in  this  domain.  Described  below  are  Mission 
Planning  specific  status  zone  and  alert  zone  conventions. 

6.2.4.1  Status  Area 

The  status  area  focuses  on  scheduling  related  information  because  of  its  importance,  volatility,  and 
time-sensitivity. 

The  following  components  are  examples  of  the  content  that  may  be  displayed  in  this  area: 

•  Schedule  Change  Requests  pending  for  the  real-time,  conflict,  and  forecast  periods 

•  Authorized  schedule  changes  for  the  real-time,  conflict,  and  forecast  periods 

•  Supports  affected  by  unplanned,  recent  changes  in  resource  availability 

6.2.4.2  Alert  and  Message  Area 

The  alert  and  message  area  follows  convention  guidance  described  in  Para.  3. 1.3.2,  Alert  Area.  The 
following  table  (Table  6.4,  Mission  Planning  Alert  Examples)  illustrates  examples  of  alerts: 
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Table  6.4.  Mission  Planning  Alert  Examples 


Criticality 

Date/Time 

Source 

Text 

W 

13/2048 

SOC -22 

Working  SOC  schedule  must  be  submitted  in  1 
hr 

W 

14/1832 

SOC -22 

Schedule  Change  Request  for  satellite  4592 
was  denied 

A 

15/2243 

Sys  Admin 

System  will  be  going  down  for  maintenance  in 

30  min. 

6.2.5  Toolbar 

Listed  below  are  the  Mission  Planning  specific  conventions  that  apply  to  toolbars: 

•  The  toolbar  may  be  located  either  above  or  below  the  status  zone  or  at  bottom  of  the  screen. 
Although  not  critical,  the  placement  of  the  toolbar  is  below  the  status  area  so  that  blocking  of 
status  information  never  occurs. 

•  The  toolbar  should  include  a  method  to  log-off,  print  a  selected  screen,  and  access  help  as 
well  as  a  convenient  way  to  navigate  to  important  areas  of  mission  planning  via  pull-down 
menu  options. 

An  example  toolbar  might  contain  the  following  options:  File,  Scheduling,  Support  Plans,  Resources, 

and  Help. 

•  The  File  option  contains  access  to  a  print  and  log-off  features. 

•  The  Scheduling  option  contains  access  to  screens  for  viewing  the  24  Hour  Schedule,  the 
Working  SOC  Schedule,  the  Weekly  Planning  Schedule  by  satellite  ID,  and  Schedule  Change 
Requests. 

•  The  Support  Plans  option  contains  access  to  screens  for  modifying  support  requirements  and 
generating  more  specialized  support  plans  such  as  Maneuver  Planning. 

•  The  Resources  option  contains  access  to  screens  for  viewing/editing  resources  availability 
forecasts  and  constraints. 

•  The  Help  option  contains  application  level  help  for  Mission  Planning  and  follows 
conventions  as  described  in  Para.  5,  Help. 

6.2.6  Mission  Planning  Specific  Conventions 

Described  below  are  the  Mission  Planning  specific  conventions. 
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6.2. 6.1  Availability  Convention 

Forecasting  future  resource  availability  is  essential  for  Mission  Planning.  Therefore,  a  real-time  status 
indicator  is  insufficient.  Instead,  availability  forecasts  should  generally  follow  the  status  conventions 
as  described  in  Table  3.1,  Color  Definitions,  and  Table  3.2,  Color  Usage  Definitions.  Predicted  future 
unavailability  or  degradation  of  resources  for  the  time  period  requested  should  appear  grayed  out  with 
the  predicted  unavailability  indicated  by  a  red  border  and  predicted  degradation  indicated  by  a  yellow 
border.  For  predicted  complete  functionality,  the  icon  (or  other  item)  should  have  black  text  and  a 
green  border  (see  status  conventions  in  Table  3.1,  Color  Definitions,  and  Table  3.2,  Color  Usage 
Definitions).  Note  that  unavailability  is  not  just  the  reported  or  predicted  operations  capability  of  the 
resource,  but  also  could  include  the  user’s  unwillingness  to  use  the  resource  in  question. 

6.2.7  Mission  Planning  Windows 

Described  below  are  conventions  specific  to  Mission  Planning  windows. 

6.2.7.1  Support  Requirements  Window 

The  Support  Requirements  window  has  various  option  menus  for  key  support  parameters  that  can  be 
changed  by  the  mission  planner  as  mission  requirements  change.  Where  there  is  a  choice  of  many 
options,  an  additional  pop-up  dialog  appears.  Functions  include:  Add,  Save,  Delete,  and  Help.  Some 
examples  of  possible  complimentary  pop-up  dialogs  containing  information  follow: 

•  Support  ID  Dialog  -  This  dialog  contains  a  scrollable  list  box  of  allowable  support  IDs  and 
several  push  buttons  at  the  bottom  including  OK,  Cancel,  and  Help. 

•  Satellite  Configuration  Dialog  -  The  Satellite  Configuration  Dialog  contains  a  scrollable  list 
box  of  allowable  satellite  configuration  settings  and  several  push  buttons  at  the  bottom 
including  OK,  Cancel,  and  Help. 

•  Additional  Hardware  Dialog  -  This  dialog  contains  a  scrollable  list  box  of  additional 
hardware  selections  that  can  be  added  to  the  support  requirements  and  some  push  buttons  at 
the  bottom  including  OK,  Add,  Cancel,  and  Help. 

6.2.7.2  Schedule  Change  Request  Window 

This  window  contains  all  essential  information  for  submitting  a  change  request  for  a  support  that  has 
to  be  coordinated  with  an  external  agency.  Most  of  the  required  information  may  be  selected  via 
option  menus.  Where  this  is  not  practical  (such  as  specifying  times)  a  text  field  appears.  The 
summary  window  holds  each  support  change  request  until  the  user  issues  a  Delete,  Clear  All,  or 
Submit  command.  These  commands  along  with  an  edit  function  are  accessible  by  push  buttons  at  the 
bottom  of  the  window.  This  screen  is  not  applicable  for  use  with  programs  that  do  not  need  to 
coordinate  their  scheduling  with  external  agencies. 

6.2.7.3  Twenty-Four  Hour  Schedule  Window 

The  24-Hr  Schedule  contains  all  the  required  data  for  an  entire  SOC’s  supports  including  IRON, 
remote  ground  facility  (RGF),  purpose,  start  and  stop  times,  resources,  and  possibly  the  personnel 
assigned  to  the  contact.  All  this  information  is  arranged  by  default  in  chronological  order  for  a  24  - 
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Hour  Schedule.  Providing  an  option  for  arranging  supports  by  other  categories  such  as  satellite  ID,  or 
RGF  may  be  useful  for  some  programs.  This  information  may  be  arranged  in  a  tabular  fashion.  As  an 
alternative  display  method,  the  24-hr  schedule  may  appear  as  a  window  with  a  timeline  appealing 
across  the  top  of  the  screen,  with  the  various  satellite  identifiers  appearing  in  sequential  order  down 
the  left  side  of  the  screen.  A  small  bar  icon  represents  each  support.  The  support  icon’s  length  and 
positioning  would  correspond  to  the  contact  duration  and  start  time  scaled  with  respect  to  the 
timeline.  Each  support  icon  may  be  accompanied  by  additional  information  such  as  the  RGF,  start  and 
stop  times,  pre-pass  length  (visible  by  text  or  visual  coding)  and  a  smaller  resource  icon.  Additional 
information  is  available  by  double-clicking  the  support  icon.  The  resource  icon  should  follow  the 
Availability  Convention  (see  Para.  6.2.6. 1,  Availability  Convention)  and  might  appear  as  a  small 
button  labeled  “R”  with  a  status  indicator  around  its  border.  Additionally,  the  color  of  the  support 
icon  may  distinguish  a  user-defined  attribute  such  as  minimum  qualification  level  to  run  the  support. 
The  look  and  feel  of  this  window  design  is  very  similar  to  the  current  Automated  Scheduling  Tools 
for  Range  Operations  (ASTRO)  system.  Some  examples  of  possible  complimentary  pop-up  dialogs 
containing  additional  information  follow: 

Support  Information  Dialog  -  This  dialog  contains  additional  information  on  a  support  such  as  pre¬ 
pass  length,  start  time,  duration,  time  tolerance. 

Resource  Availability  Dialog  -  This  dialog  is  accessed  by  clicking  the  resource  icon  and  contains 
additional  information  on  the  resources  available  for  the  selected  support. 

6.2.7.4  Working  SOC  Schedule  Window 

This  window  follows  the  same  basic  design  as  the  graphical  version  of  the  24  Hour  schedule.  A 
timeline  appears  across  the  top  of  the  screen,  with  the  various  satellite  identifiers  appearing  in 
sequential  order  down  the  left  side  of  the  screen.  A  small  icon  appears  for  each  support  similar  to  the 
support  icon  in  the  24-Hr  Schedule  window  (see  Para.  6. 2. 7. 3,  Twenty-Four  Hour  Schedule  Window) 
but  may  contain  slightly  different  information  depending  on  mission  requirements.  Possible 
information  may  include  RGF,  start  and  stop  times,  time  tolerance,  and  pre-pass  length.  Also,  any 
additional  information  is  available  by  double-clicking  the  support  icon.  The  look  and  feel  of  this 
window  design  is  very  similar  to  the  current  ASTRO  system.  An  example  of  a  possible 
complimentary  pop-up  dialog  containing  additional  information  follows: 

Support  Information  Dialog  -  This  dialog  contains  additional  information  on  a  support  such  as  pre¬ 
pass  length,  start  time,  duration,  time  tolerance,  and  RGF. 

6.2.7.5  Planning  Schedule  Window 

The  Planning  Schedule  contains  all  the  required  data  for  a  particular  satellite,  for  a  given  time  period 
(typically  a  week),  arranged  in  chronological  order.  Key  information  would  include  IRON,  start  and 
stop  times,  time  tolerance,  RGF  visibilities  or  preferences,  resources  needed,  purpose  and  any 
comments  or  constraints.  This  way  of  planning  a  schedule  may  be  unnecessary  if  a  schedule  generator 
can  encompass  all  the  functionality. 
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6.2.7.6  Schedule  Generator  Window 


The  Schedule  Generator  is  an  automated  method  for  generating  a  support  schedule.  The  Schedule 
Generator  window  contains  all  the  required  routine  support  types  and  the  frequency  with  which  they 
must  be  performed  for  a  given  satellite.  Additionally,  it  has  a  place  to  insert  special  support  types. 
Additional  constraints  should  be  able  to  be  applied  such  as  specifying  the  RGF,  time  window, 
minimum  /maximum  elevation  angle,  non-collocated  RGFs,  and  the  ability  to  treat  multiple  supports 
as  one  suite  of  supports  that  follows  an  all  or  nothing  algorithm  for  scheduling.  When  all  the 
information  is  completed,  a  button  activates  the  generation  of  a  schedule  for  a  given  time  period  for 
that  vehicle.  This  window  eliminates  the  need  for  the  more  manual  Planning  Schedule  approach. 
However,  manual  scheduling  may  still  be  preferred  for  programs  that  have  a  lot  of  specialized  needs 
and  exceptions  or  for  programs  that  have  very  few  support  requirements. 

6.2.7.7  External  Message  Window 

The  External  Message  Window  is  a  vertically  scrolled  window  containing  the  details  of  an  externally 
generated  message.  Each  message  includes  the  originating  agency,  time  tag  and  sender’s 
identification  in  the  message.  This  window  may  be  used  as  an  expanded  version  of  a  message 
contained  in  the  alert  area  of  the  Mission  Planning  Status  Zone. 

6.2.7.8  Maneuver  Planning  Window 

This  window  contains  an  option  menu  selection  for  satellite  identifier  and  maneuver  type.  When  the 
user  selects  a  satellite  identifier  and  a  maneuver  type,  the  rest  of  the  window  fills  in  with  the 
appropriate  satellite  specific  and  maneuver  specific  configurations  as  well  as  an  option  to  import 
essential  parameters  such  as  burn  time,  burn  duration,  etc.  Some  programs  may  benefit  from  the 
additional  flexibility  of  allowing  the  operator  to  input  data  type,  time,  and  duration  as  a  precursor  to 
an  external  application  generating  the  maneuver  plan.  When  complete,  the  Mission  Planner  can  select 
the  “Generate  SSP”  button  to  complete  the  fill-ins  in  the  appropriate  engineer  approved  Satellite 
Support  Plan. 

6.2.7.9  Resource  Availability  Forecast  Window 

The  Resource  Availability  Forecast  window  contains  a  world  map  with  important  resources 
represented  by  hierarchical  icons  in  their  respective  geographical  location.  Each  hierarchical  icon 
conforms  to  the  Availability  Convention  (see  Para.  6.2.6. 1,  Availability  Convention).  An  option  menu 
exists  for  filtering  according  to  a  particular  family’s  user  defined  constraints.  A  horizontal  slider  bar 
is  included  for  selecting  a  future  date  of  interest  and  is  located  in  the  upper  right-hand  corner.  All  the 
resource  icons  on  the  map  change  to  reflect  the  forecasted  availability  for  the  chosen  date  or  range  of 
dates  by  changing  the  date  in  the  slider  bar. 

6.2.7.10  RGF  Availability  Window 

This  window  is  activated  in  a  drill  down  manner  from  a  hierarchical  icon  located  in  the  Resource 
Availability  Forecast  window.  This  window  contains  forecasted  availability  of  the  Remote  Ground 
Facility’s  telemetry,  tracking,  and  commanding  capabilities  as  well  as  scheduled  downtimes  and 
estimated  time  to  return  to  operation.  This  window  conforms  to  the  Availability  Convention  (see 
Para.  6.2.6. 1,  Availability  Convention).  The  window  often  overlaps  the  Resource  Availability 
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Forecast  window  because  it  functions  similarly  to  a  dialog  box. 

6.2.7.11  SOC  Availability  Window 

The  SOC  Availability  window  is  activated  in  a  drill-down  manner  from  a  hierarchical  icon  displayed 
in  the  Resource  Availability  Forecast  window.  This  window  contains  forecasted  availability  of  the 
SOC’s  key  operations  strings,  cryptographic  equipment,  and  mission  unique  equipment  as  well  as 
scheduled  downtimes  and  estimated  time  to  return  to  operation.  This  window  conforms  to  the 
availability  convention.  Also,  this  window  often  overlaps  the  Resource  Availability  Forecast  window 
because  its  behavior  is  similar  to  a  dialog  box. 

6.2.7.12  Satellite  Control  Node  Availability  Window 

This  window  is  activated  in  a  drill-down  manner  from  a  hierarchical  icon  located  in  the  Resource 
Availability  Forecast  window.  A  Satellite  Control  Node  may  represent  any  resource  or  agency, 
besides  RGFs  and  the  operations  center  that  provide  mission  essential  resources  or  links.  For 
example,  Schriever  Control  contains  forecasted  availability  of  its  key  communication  links  as  well  as 
scheduled  equipment  downtimes  and  estimated  time  to  return  to  operation.  This  window  conforms  to 
the  Availability  Convention  (see  Para.  6.2.6. 1,  Availability  Convention).  The  window  often  overlaps 
the  Resource  Availability  Forecast  window  because  it  functions  similarly  to  a  dialog  box.  This 
window  is  most  applicable  for  programs  that  use  common  AFSCN  resources  or  need  Schriever 
Control  for  external  connectivity,  but  may  be  used  by  any  program  that  needs  to  status  a  non-RGF 
control  node  outside  of  their  operations  center. 

6.3  Satellite  Orbit  and  Attitude  Management  Conventions 

6.3.1  Description 

Orbit  and  attitude  domain  activities  are  related  to  maintaining  each  satellite’s  correct  orbit  (path 
through  space)  and  attitude  (orientation  with  respect  to  the  Earth,  Sun  or  other  celestial  objects).  This 
includes  developing  orbit  and  attitude  state  vectors,  generating  ephemeris/event  products,  generating 
orbit  station-keeping  and  attitude  maintenance  maneuvers.  Also  included  in  the  domain  is  the 
production  of  station  visibilities,  RFI  conjunction  projections,  predictions  of  close  approach  to  other 
space  objects  and  interfacing  with  IRO. 

6.3.2  COTS/GOTS  Tools 

There  are  many  COTS  tools  available  to  perform  Orbit  and  Attitude  Management  functions;  these 
packages  vary  in  their  focus  and  specialization.  The  developer  using  these  conventions  would  be  well 
served  by  reviewing  applicable  COTS  and  government  off  the  shelf  (GOTS)  tools,  with  the  goal  of 
incorporating  them  and  their  conventions  where  it  makes  sense  to  do  so.  Some  conventions  from 
Satellite  Tool  Kit  (STK)  from  Analytical  Graphics,  Inc.,  and  OASYS  from  Integral  Systems,  Inc.  are 
identified  in  the  Developer’s  Style  Guide. 

6.3.3  Screen  Layout 

Described  below  is  screen  layout  information  regarding  arrangement  of  windows  and  navigation, 
rules  on  overlapping  windows,  as  well  as  definitions  and  handling  criteria  for  critical  information. 
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6.3.3.1  Arrangement  of  Windows  and  Navigation 

Listed  below  are  the  orbit  and  attitude  specific  convention  alternatives  for  arrangement  and 
navigation  of  windows.  The  operational  unit  can  select  from  among  these  alternatives: 

•  In  the  Orbit  and  Attitude  domain,  most  functions  are  sequential  in  nature,  beginning  with  one 
window  and  progressing  through  others.  For  this  reason,  windows  in  this  domain  provide  the 
names  of  both  the  function  thread  and  the  window  within  the  tread.  The  preferred  alternative 
is  to  name  windows  by  the  scheme  Thread:  Window  so  as  to  take  up  only  one  line.  Another 
alternative  is  to  have  the  Thread  name  on  one  line  and  the  Window  name  on  another  line. 

This  requires  two  lines  (hence,  more  screen  real  estate)  and  is  more  difficult  to  develop. 

•  The  preferred  arrangement  is  to  default  to  a  scheme  where  the  parent  window  stays  visible  in 
work  zone,  through  perhaps  partially  or  fully  covered  by  other  windows,  during  child  window 
processing  with  a  user  option  to  be  able  to  select  the  following  alternative.  Most  user 
comments  favor  this  approach.  An  alternate  approach  is  for  the  parent  window  to  disappear 
from  work  zone  until  processing  of  child  window  is  complete,  and  then  re-appear. 

•  All  windows  in  sequential  processing  threads  normally  have  the  ability  to  navigate  backward 
one  window  in  the  process,  backward  to  the  beginning  of  the  process,  and  to  exit  the  process 
completely. 

•  Accelerator  and  function  shortcut  keys  are  available  for  frequently  used  functions.  Examples 
of  functions  available  from  shortcut  keys  are  described  in  Para.  2.3,  Navigation  Keys  and 
Techniques. 

6.3. 3.2  Rules  on  Overlapping  Windows 

Satellite  Orbit/ Attitude  Management  is  not  directly  involved  with  real-time  operations;  therefore 
window  overlapping  (cascading)  is  allowed.  Refer  to  Para.  2.5,  Use  of  Multiple  Windows  on  a  Single 
Display,  for  rules  on  overlapping  windows.  As  a  general  rule,  children  windows  should  not  overlap  a 
parent  window. 

6.3.3.3  Definition  and  Handling  of  Critical  Information 

This  definition  and  handling  of  critical  information  follows  the  conventions  described  in  Para.  3. 1.3.2, 
Alert  Area.  There  are  no  critical  alerts  specific  to  this  domain. 

6.3.4  Header  zone 

The  header  zone  for  Orbit  and  Attitude  Management  utilizes  the  conventions  as  described  in  Para. 
3.1.2,  Header  Zone. 

6.3.5  Status  Zone 

Described  below  are  the  Orbit  and  Attitude  specific  status  area  and  alert  area  conventions.  Note: 

Since  the  Orbit  and  Attitude  domain  does  not  require  very  extensive  status  feedback,  a  smaller  status 
area  and  larger  work  zone  is  needed.  The  section  below  describes  status  area  and  alert  area 
conventions. 
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6.3.5.1 


Status  Area 


Processes  and  Status  are  examples  of  information  pertinent  to  the  Orbit/ Attitude  status  area. 

6.3.5.1.1  Processes 

The  Process  window  is  used  to  display  a  list  of  active  processes  with  summary  identification  of  each. 
Table  6.5  shows  Process  examples  combined  with  status  described  below. 

6.3.5.1.2  Resource/Activities  Status 

The  latest  status  message  for  each  process  is  shown  in  the  alert  area  adjacent  to  that  process’s  entry  in 
the  Process  panel.  Double-clicking  on  a  status  entry  causes  a  pop-up  scroll  box  to  appear  providing  a 
history  of  all  the  status  messages  that  Process  has  generated.  Table  6.5  includes  examples  of 
Processes  and  their  Status. 


Table  6.5.  Orbit  and  Attitude  Process  Examples 


ProcID 

UserlD 

Start 

Status 

UpdateOrbitStateVectorOl 

Jdoe 

177/16:19:30 

Iteration  9:  Diverged  -  Aborted 

ProcessTrackingO  1 

Jdoe 

177/16:20:00 

Error  Check:  25  points  discarded 

6.3. 5.2  Alert  and  Message  Area 

The  alert  and  message  area  follows  conventions  described  in  Para  3. 1.3.2  Alert  Area.  The  following 
and  Table  6.6  provides  category  examples  of  alerts: 

•  The  Alert  and  Message  Area  provides  system  messages,  non-specific  to  active  processes,  as 
well  as  processing  error  messages  pertinent  to  active  processes. 

•  System  message  types  include:  system  abends,  security  alarms,  hardware/software 
problems/updates,  networking  problems/updates,  database  problems/updates  and  system 
feedback. 

•  Process  error  message  types  include:  unexpected  end  of  file  encountered,  abnormal  process 
termination,  process  input  expected,  and  other  messages  necessary  for  documenting,  in  a  log, 
problems  with  the  running  processes. 

Table  6.6.  Orbit  and  Attitude  Alert  Examples 


Criticality 

Date/Time 

Source 

Text 

W 

194/16:20:25 

1234 

Unexpected  end  of  file  encountered 

W 

194/16:20:29 

1234 

Tracking  data  not  processed 

Examples  of  sources  in  Table  6.6  are  IRONs,  satellite  identifiers,  equipment,  processors,  external 
dependencies,  etc. 
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6.3.6  Toolbar 


Listed  below  are  the  Orbit  and  Attitude  specific  conventions  that  apply  to  toolbars: 

The  placement  of  the  toolbar  is  not  critical  (top/  bottom  of  status  area  or  bottom  of  screen) 

Menu  Items  -  order  choices  by  functional  groups  or  frequency  of  use. 

•  File  -  Print  and  Logoff 

•  Orbit  -  Process  Tracking  Data,  Update  Orbit  State  Vector  and  Generate  Orbit  Products 

•  Attitude  -  Process  Attitude  Data,  Update  Attitude  State  Vector  and  Generate  Attitude 
Products 

•  Database  -  Maintain  Database,  Maintain  Controls,  Enter  New  IRONs  (satellite  identifiers) 
and  Import  and  Export  Orbit  and  Attitude  Data 

•  Maneuver  Planning  -  Initiate  Orbit  and  Attitude  Maneuver  Planning 

•  Program-specific  -  Constellation  Management  and  Other  Program-specific  Functions 

•  Flelp  -  General  help  for  system  and  Orbit/ Attitude  functions. 

6.3.7  Orbit  and  Attitude  Management  Specific  Conventions 

Described  below  are  the  Orbit  and  Attitude  Management  specific  conventions. 

•  Classification  Issues:  Inclusion/combination  of  certain  fields  can  make  the  window  content 
classified.  The  following  possible  alternatives  may  be  utilized: 

a)  Exclude  fields  and  prevent  associations  in  order  to  maintain  an  unclassified 
environment. 

b)  Substitute  unclassified  designators  for  entities  whose  inclusion  would  make  a  window 
classified. 

c)  Accommodate  classified  windows  with  proper  controls,  procedures  and  markings. 

Ensure  that  the  operator/viewer  has  proper  authority  to  view  classified  screens  by 
password  or  other  control  method.  Multiple-level  security  environment  must  be 
given  consideration. 

•  Store/Recall  Issues:  satellite  programs  need  to  devise  a  store/recall  convention  whereby 
filenames  and/or  properties  are  used  in  a  way  that  quickly  identifies  important  characteristics 
of  the  file.  These  characteristics  could  then  be  searched  on  upon  subsequent  recall 
procedures.  An  example  of  file  properties  follows  the  Properties  sheet  attached  to  Microsoft® 
Word®  documents.  As  an  example  of  a  file  naming  scheme  for  tracking  data  files,  the 
following  is  suggested: 
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IRON  date  site-side  condition  with: 

IRON:  four  digit  IRON  date:  date  in  YYYYMMDD  format 
site-side:  RGF  antenna  taking  the  data 
cond:  raw  or  proc(essed) 

•  Common  Conventions:  Orbit  and  Attitude  domain  windows  use  the  conventions  described  in 
Sections  1  through  5  with  a  few  additions  as  described  under  the  appropriate  windows.  In 
general,  widgets  have  been  selected  to  minimize  required  operator  effort  and  typing,  and  to 
circumvent  input  errors.  For  example,  combo  boxes,  which  embody  pull-down  lists,  are 
predominant  for  the  selection  of  IRONs.  But  they  also  allow  the  operator  to  type  in  the  IRON 
of  interest,  if  he/she  so  chooses.  In  this  manner,  an  operator  can  use  whichever  method  he/she 
finds  most  efficient. 

6.3.8  Orbit  Management  Windows 

The  following  windows  are  used  for  Orbit  Management. 

6.3. 8.1  Process  Tracking  Data 

The  following  windows  are  related  to  processing  tracking  data  to  be  used  in  updating  the  orbit  state 
vector. 

6.3.8.1.1  Process  Tracking  Data  Window 

This  window  is  used  to  process  tracking  data  by  error  checking  and  thinning.  An  Orbit-specific 
widget  used  for  input  in  this  window  is  the  Linked  input  field.  Linked  input  fields  a  -  %  (sigma  - 
percentile),  are  such  that  a  is  linked  with  %  such  that  an  entry  in  the  a  field  generates  an  entry  in  the 
%  field  that  is  the  percentile  corresponding  to  that  o,  and  vice-versa.  Using  this  widget,  an  operator 
can  input  error  limits  in  either  sigma  values  or  percentiles,  whichever  he/she  prefers,  and  the 
corresponding  value  in  the  other  units  is  displayed  automatically. 

6. 3. 8.1. 2  Select  Tracking  Data  Sets  Window 

This  window  allows  the  user  to  select  tracking  data  sets  by  name,  time  span  or  rev  span.  It  is  in 
response  to  user  comments  requesting  the  ability  to  select  Lacking  data  sets  by  time  span,  and  to  be 
able  to  view,  edit,  or  deselect  specific  tracks.  Note  that  this  window  is  also  related  to  updating  the 
orbit  state  vector. 

6. 3. 8.2  Update  Orbit  State  Vector  Windows 

The  following  windows  are  related  to  updating  the  orbit  state  vector. 

6. 3. 8.2.1  Update  Orbit  State  Vector  Window 

This  window  allows  the  user  to  update  the  orbit  state  vector  by  selecting  an  IRON ;  it  uses  defaults  for 
all  other  parameters.  It  is  in  response  to  user  comments  requesting  expanded  use  of  defaults  in 
simplifying  Orbit  operations.  For  scenarios  where  access  to  more  processing  details  is  required,  it 
provides  access  to  windows  for  both  controls  and  estimation  details. 
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6.3. 8.2.2  Update  Orbit  State  Vector:  Controls  Window 

This  window  allows  the  user  to  modify  controls  used  to  update  the  orbit  state  vector.  It  provides 
access  to  detailed  and  varied  controls  used  in  state  vector  update  processing. 

6.3. 8.2. 3  Orbit  State  Vector:  Estimation  Window 

This  window  provides  the  user  access  to  details  in  the  orbit  estimation  process.  It  provides  access  to 
“hands-on”  state  vector  update  processing.  It  also  provides  more  extensive  results  than  the  Update 
Orbit  State  Vector  window. 

6.3. 8.2.4  Update  Orbit  State  Vector:  Residual  Editing  Window 

This  window  allows  the  operator  to  graphically  edit  residuals.  Graphical  residual  editing  is  much 
preferred  to  editing  tables  of  numbers  since  residual  patterns  are  not  evident  from  such  tables  whereas 
they  are  immediately  visible  in  a  graph. 

6.3.8.3  Generate  Orbit  Products 

The  following  windows  are  related  to  generating  orbit  products. 

6.3. 8.3.1  Generate  Orbit  Products  Window 

This  window  allows  users  to  generate  Orbit  products,  such  as  Ephemeris  and  Events,  Antenna 
Pointing  Angles,  Station  Accesses,  RFI  conjunctions,  etc. 

6. 3. 8.3.2  Orbit  Ephemeris  and  Events  Window 

This  window  allows  the  user  to  generate  Orbit  ephemeris  and  events.  The  use  of  tabs  in  the  window 
allows  multiple  views  to  be  compacted  into  one  window,  making  it  easier  to  manage  a  fewer  number 
of  windows.  This  example  includes  a  menu  bar  common  to  all  tabs. 

6.3.8.3.3  Orbit  Ephemeris  and  Events  Window:  Orbit  State  Tab 

This  tab  allows  the  user  to  set  the  orbit  state  to  be  used  in  ephemeris  propagation  and  events 
generation. 

6.3.8.3.4  Orbit  Ephemeris  and  Events  Window:  Report  Controls  Tab 

This  tab  allows  the  user  to  set  controls  on  how  the  report  is  to  be  generated. 

6.3. 8.3. 5  Orbit  Ephemeris  and  Events  Window:  Ephemeris  Controls  Tab 

This  tab  allows  the  user  to  set  controls  on  the  generation  of  ephemeris.  Widgets  used  for  input  include 
spin  buttons  on  fields  of  related  parameters  that  are  linked  in  such  a  manner  that  changing  one 
parameter  changes  the  other  linked  parameters  accordingly. 

6. 3. 8.3. 6  Orbit  Ephemeris  and  Events  Window:  Events  Controls  Tab 

This  window  allows  the  user  to  set  controls  on  the  generation  of  events.  Widgets  used  for  input 
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include  a  pick-and-put  linked  to  toggle  buttons.  This  linkage  is  such  that  selecting  a  toggle  button 
causes  the  corresponding  parameters  to  move  from  the  “Available”  side  of  the  pick-and-put  widget  to 
the  “Selected”  side. 

6.3.9  Attitude  Management  Windows 

The  following  functions  reside  under  the  Attitude  menu. 

6.3. 9.1  Process  Attitude  Data 

The  conventions  for  Process  Tracking  Data  under  the  Orbit  menu  are  directly  applicable  to  this 
function  due  to  the  similarity  of  operations. 

6.3.9.2  Update  Attitude  State  Vector 

The  conventions  for  Update  Orbit  State  Vector  under  the  Orbit  menu  are  directly  applicable 
to  this  function  due  to  the  similarity  of  operations. 

6.3.9.3  Generate  Attitude  Products 

The  conventions  for  Generate  Orbit  Products  under  the  Orbit  menu  are  directly  applicable  to  this 
function  due  to  the  similarity  of  operations. 

6.3.10  Database  Windows 

This  menu  leads  to  the  Maintain  Database,  Maintain  Controls,  Enter  New  IRON  (satellite  identifier), 
Force  Model  Controls  and  Station  Parameters  options. 

6.3.10.1  Import  Orbit/ Attitude  Data  Windows 

Windows  for  Import  Orbit/Attitude  Data  follow: 

6.3.10.1.1  Import  Orbit/Attitude  Data:  Source  and  Type  Window 

This  window  allows  a  user  to  import  Orbit/ Attitude  data.  Data  source  and  type  are  selected 
here. 

6.3.1 0.1 .2  Import  Orbit/ Attitude  Data:  State  Vector  Windows 

This  window  allows  the  user  to  import  Orbit  State  Vector  data. 

6.3.1 0.1 .3  Keplerian  Elements  Window 

This  window  allows  a  user  to  import  Orbit  State  Vector  data  in  Keplerian  Elements. 

6.3.1 0.1 .4  Import  Orbit/Attitude  Data:  Maneuver  Window 

This  window  allows  a  user  to  import  Orbit/ Attitude  Maneuver  data. 
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6.3.10.2  Export  Orbit/ Attitude  Data  Windows 

Described  below  are  conventions  specific  to  Export  Orbit/Attitude  Data  windows. 

6.3.10.2.1  Export  Orbit/Attitude  Data:  Destination  and  Type  Window 

This  window  allows  the  user  to  export  Orbit/ Attitude  data.  Data  destination  and  type  are  selected 
here. 

6.3.10.2.2  Export  Orbit/Attitude  Data:  Orbit  Events  Window 

This  window  allows  a  user  to  export  Orbit  Events  data. 

6.3.10.2.3  Orbit  Events:  Report  Window 

This  window  allows  the  user  to  export  Orbit  Events  data  for  selected  events. 

6.3.10.3  Force  Model  Controls  Windows 

The  following  are  windows  pertaining  to  force  model  controls. 

6.3.10.3.1  Force  Model  Controls  Window 

This  window  allows  the  user  to  set  force  model  controls. 

6.3.1 0.3.2  Orbit  Maneuvers  Window 

This  is  another  window  with  which  to  import  orbit  maneuvers. 

6.3.10.4  Station  Data  Windows 

6.3.10.4.1  Station  Parameters  Window 

This  window  allows  user  to  set/modify  station  parameters.  Selecting  any  one  of  the  four  check  boxes, 
Position  Data,  Obscura  Data,  Measurand  Data,  and/or  Other  Station  Data,  brings  up  a  window 
specific  to  that  data.  Any  or  all  check  boxes  can  be  selected  at  any  time,  resulting  in  windows 
corresponding  to  all  options  selected. 

6.3.10.4.2  Station  Parameters:  Position  Data  Window 

This  window  allows  the  user  to  set/modify  station  position  parameters,  such  as  latitude,  longitude, 
elevation,  and  their  corresponding  uncertainties. 

6.3.10.4.3  Station  Parameters:  Obscura  Data  Window 

This  window  allows  a  user  to  set/modify  station  obscura  parameters,  which  basically  are  minimum 
elevation  angles  for  visibility  as  a  function  of  azimuth. 
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6.3.10.4.4  Station  Parameters:  Measurand  Data  Window 


This  window  allows  the  user  to  set/modify  station  measurand  parameters,  which  are  biases  and 
uncertainties  related  to  antenna  measurements. 

6.3.10.4.5  Station  Parameters:  Other  Station  Data  Window 

This  window  allows  the  user  to  set/modify  other  station  parameters,  such  as  refraction  correction 
coefficients,  inospheric  and  tropospheric  delay  parameters,  etc. 

6.3.11  Maneuver  Planning  Windows 

Described  below  are  conventions  specific  to  Maneuver  Planning  windows. 

6.3.11.1  Orbit  Maneuver  Planning  Windows 

The  following  windows  implement  maneuver  planning  functions  for  one  type  of  orbital  maneuver: 
East-West  Station-keeping. 

6.3.11.1.1  Orbit  Maneuver  Planning  Window 

This  window  allows  a  user  to  select  an  IRON  and  maneuver  type,  and  plan  the  maneuver  and 
generate  maneuver  parameters. 

6.3.1 1 .1 .2  Orbit  Maneuver  Constraints  Window 

This  window  allows  the  user  to  set  special  maneuver  constraints,  such  as  maximum  delta-V, 
maximum  propellant  used,  etc. 

6.3.1 1 .1 .3  Orbit  Maneuver  Results  Window 

This  window  allows  the  user  to  view  numerical  results  of  the  maneuver  plan.  It  also  provides  access 
to  a  graphical  results  window. 

6.3.1 1 .1 .4  Orbit  Maneuver  Graph  Window 

This  window  provides  graphical  depiction  of  E/W  station-keeping  maneuver  results.  Widgets  used  for 
output  include  a  graph. 

6.4  Satellite  Engineering  Analysis  Conventions 
6.4.1  Description 

The  Satellite  Engineering  domain  provides  the  technical  details  necessary  to  operate  complex  satellite 
systems.  This  includes,  developing,  validating  and  maintaining  a  library  of  SSPs,  monitoring  the  state 
of  health  of  assigned  satellites,  developing  anomaly  resolution  plans/satellite  safe-mode  procedures, 
and  assisting  in  out-of -procedure  anomaly  resolution. 
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6.4.2  Screen  Layout 

Described  below  is  screen  layout  information  regarding  arrangement  of  windows  and  navigation, 
rules  on  overlapping  windows,  as  well  as  definitions  and  handling  criteria  for  critical  information. 

6.4.2. 1  Arrangement  of  Windows  and  Navigation 

Accelerator  and  function  shortcut  keys  are  available  for  frequently  used  buttons.  Examples  of 
functions  requiring  shortcut  keys  are  in  Table  6.7  Engineering  Analysis  Default  Shortcut  Key 
Definitions. 


Table  6.7.  Engineering  Analysis  Default  Shortcut  Key  Definitions 


Shortcut 

Key 

Function  /  Action 

F3 

Schedules  submitted  to 
scheduling 

F4 

Future  Schedules 

F5 

Planned  Maneuvers 

6.4.2.2  Rules  on  Overlapping  Windows 

Engineering  analysis  is  not  directly  involved  with  real-time  data  management,  therefore  window 
overlapping  (cascading)  is  allowed.  Refer  to  Para.  2.5,  Use  of  Multiple  Windows  on  a  Single  Screen 
Display,  for  more  information. 

6.4.2.3  Definition  and  Handling  of  Critical  Information 

The  definitions  and  handling  of  critical  information  follows  the  conventions  described  in  Para. 

3. 1.3.2,  Alert  Area.  Refer  to  this  paragraph  for  examples. 

6.4.3  Header  Zone 

The  header  zone  for  Engineering  Analysis  utilizes  the  conventions  as  described  in  Para.  3.1.2,  Header 
Zone.  The  information  items  that  are  the  most  useful  for  this  domain  are  classification  and  operational 
mode. 

6.4.4  Status  Zone 

The  status  zone  is  made  up  of  the  status  area  and  the  alert  area.  The  section  below  describes 
Engineering  Analysis  specific  status  area  and  alert  area  conventions. 

6.4.4.1  Status  Area 

The  status  area  contains  information  pertinent  to  the  Engineering  Analysis  functions.  The 
following  components  are  examples  of  the  content  that  may  be  displayed  in  the  status  area. 
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This  area  may  be  comprised  of  a  schedule  of  upcoming  and  current  contacts.  The  schedule  typically 
shows  contact  specific  information  such  as  start  time,  stop  time,  RTS/Type,  front  end  processor 
(FEP),  Mode,  Purpose,  and  the  operator  assigned  to  the  contact.  The  schedule  can  be  sorted  by 
column  headings.  The  sorts  can  toggle  between  ascending  order  and  descending  order  as  a  title 
heading  is  clicked. 

Another  possible  implementation  of  the  status  area  is  to  use  a  smaller  schedule.  The  number  of 
columns  displayed  in  the  schedule  could  be  reduced.  The  decreased  schedule  size  allows  for  buttons 
with  direct  access  to  windows.  Examples  of  the  types  of  windows  accessed  by  a  button  are  network 
resources  status,  long  term  vehicle  planning,  or  working  SOC  schedule. 

6.4.4.2  Alert  and  Message  Area 

The  alert  and  message  area  follows  the  conventions  described  in  Para.  3. 1.3. 2,  Alert  Area.  The  source 
of  the  alert  can  be: 

•  IRON,  such  as  1234 

•  Flight  Number,  such  as  Family  1  vehicles 

•  Vehicle  subsystem,  such  as  Guidance 

•  Ground  equipment,  such  as  ARTS 
Table  6.8  provides  examples  of  alerts: 

Table  6.8.  Engineering  Analysis  Alert  Examples 


Criticality 

Date/Time 

Source 

Text 

A 

149/00:45:00 

1234 

Parameter  Heater  A  not  found  in  database 

W 

149/00:42:00 

1234 

L-Limits  w/in  5  degrees  of  H-Limit 

E 

149/00:41:00 

1234 

Parameter  A  Side  Status  Limit  Set  updated 

E 

149/00:40:00 

1234 

Eclipse  Trending  Set  Activated 

6.4.5  Toolbar 

The  placement  of  the  toolbar  is  not  critical,  because  operations  in  this  domain  are  not  time  critical. 
Listed  below  are  the  Engineering  Analysis  specific  conventions  that  apply  to  menu  items  in  the 
toolbar: 

•  Playback  -  Telemetry  and  Trending 

•  SSP  -  Editing  and  Creating 

•  Sets  -  Trending  and  Limit 

•  Block  Command  -  Maintenance 
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•  Derived  Telemetry  -  Editing  and  Creating. 

6.4.6  Engineering  Analysis  Specific  Conventions 

The  section  below  describes  conventions  utilized  in  Engineering  windows: 

6.4. 6.1  Automatic  Data  Selection 

The  Automatic  Data  Selection  convention  uses  system  or  user  input  to  populate  other  input  fields. 

The  example  used  in  this  area  utilizes  a  file  naming  convention  (e.g.,  Julian  date/time_IRON)  to 
select  other  parameters  (IRON).  For  example,  if  the  user  selects  the  001/0001_1234,  the  function 
automatically  selects  the  1234  IRON.  This  feature  minimizes  the  number  of  selections  that  the  user 
has  to  make.  This  is  the  only  domain  that  utilized  this  common  function. 

6.4. 6.2  Radio  Button  and  Option  Menu  Group 

Radio  buttons  are  used  to  make  a  selection  of  a  category.  An  option  menu,  associated  with  the 
selected  button,  is  used  to  make  specific  choices  within  a  category.  This  convention  is  used 
extensively  in  this  domain. 

6.4. 6.3  Pick-and-Put  and  Identifier  Group 

This  convention  combines  the  functionality  of  pick-and-put  buttons  with  an  option  menu.  The  pick- 
and-put  function  is  used  to  move  data  items  between  lists.  The  option  menu  is  used  to  attach  an 
identifier  to  the  data  items.  When  the  data  item  is  selected  an  identifier  is  added  to  a  data  item  and 
both  are  moved  to  the  new  list.  This  is  the  only  domain  that  utilized  this  specific  convention. 

6.4. 6.4  Positional  Pick-and-Put  Buttons 

This  convention  is  used  in  conjunction  with  the  directional  arrow  pick-and-put  and  identifier  group 
convention.  It  provides  additional  push  buttons  for  repositioning  items  in  a  list.  An  item  in  the  list  is 
selected  and  the  up  arrow  is  activated  to  move  the  item  up  one  position  in  the  list.  The  down  arrow 
button  activates  the  opposite  behavior.  If  the  item  is  at  one  end  of  the  list  and  the  next  button 
activation  would  remove  the  item  from  that  end  of  the  list,  the  item  is  allowed  to  “wrap  around”  to  the 
other  end  of  the  list.  For  example  an  item  at  the  top  of  the  list  is  selected.  The  user  activates  the  up 
button  and  the  item  then  appears  at  the  bottom  of  the  list.  This  is  the  only  domain  that  utilized  these 
specific  functions  of  the  pick-and-put  convention. 

6.4.7  Engineering  Analysis  Windows 

The  section  below  describes  conventions  utilized  in  Engineering  Analysis  Windows. 

6.4.7.1  Edit/New  Trending  Sets  Window 

This  window  allows  a  user  to  update  or  create  a  trend  set.  A  trend  set  is  a  collection  of  telemetry 
parameters  that  pertain  to  one  area  of  the  vehicle.  The  trend  set  is  recorded  to  obtain  a  history  of  one 
area  of  the  vehicle  data  that  is  easily  viewed  by  the  user.  This  window  uses  a  version  of  ‘pick-and- 
put’  that  depicts  adding  another  descriptive  parameter  when  the  data  is  moved  to  the  destination  list. 
To  use  this  version  of  the  pick-and-put,  the  user  chooses  to  add  a  timer  (every  X  duration).  For  this 
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window,  the  timer  defines  the  number  of  times  a  parameter  is  recorded.  The  timer  defines  the  number 
of  times  a  parameter  is  recorded.  The  duration  timer  value  does  not  change  unless  the  user  changes  it. 
Items  are  copied  from  the  source  list  (Available  Parameters)  to  the  destination  list  (Selected 
Parameters).  If  multiples  of  the  same  item  are  not  allowed  in  the  list  being  created,  once  the  item  is 
moved  into  the  new  list  it  is  deleted  from  the  source  list.  There  is  a  time  span  on  the  history  data  for 
the  user  to  define  the  duration  of  the  history  table  or  graph.  The  user  defines  the  start  time  by  day, 
month,  year,  and  hour.  The  duration  input  field  accepts  numeric  data  and  an  option  menu  contains  the 
interval  selections  such  as  minutes,  hours,  days,  etc.  There  are  buttons  to  access  windows  to  view  the 
history  of  the  trend  set  in  a  table  or  graph  format.  A  Limit  Set  button  allows  access  to  the  limit  set 
windows.  The  Save  and  Close  buttons  follow  the  definitions  described  in  Table  4.1,  Common  Button 
Actions. 

6.4.7.2  Build  New  Satellite  Support  Plan  Window 

This  window  uses  a  version  of  pick-and-put  to  move  data  items  between  the  source  and  the 
destination  list.  An  additional  feature  is  the  positional  pick-and-put  buttons  to  reorder  data  items  in 
the  destination  list.  The  selected  or  highlighted  item  in  the  component  list  is  moved  by  selecting  the 
up  or  down  arrow.  The  item  moves  once  for  each  arrow  selection.  For  convenience  ‘Definition  of 
Data’  is  used  to  describe  items  in  the  available  component  list.  The  ‘radio  button  and  option  menu 
group’  convention  is  used  to  select  the  SSP  scope.  The  Validate  button  verifies  that  the  components 
are  in  a  logical  and  operationally  sound  execution  order.  The  Approve  button  verifies  that  the 
component  has  been  reviewed  and  is  ready  for  operational  use.  The  Save  and  Close  buttons  follow  the 
definitions  found  in  the  Table  4.1,  Common  Action  Buttons.  Recommendations  for  this  window  are: 

•  Adding  a  time  tag  function 

•  Adding  a  flow  charting  tool  to  build  and  edit  the  SSP 

•  Capability  to  viewing  another  SSP  to  help  in  building  a  new  SSP. 


6.4.7.3  SSP  Build  Satellite  Block  Commands  Window 

This  window  uses  the  pick-and-put  convention  to  move  individual  commands  into  a  block  command 
list.  Positional  pick-and-put  buttons  allow  the  user  to  change  the  order  of  a  selected  item  (up  or  down 
in  the  selected  list).  This  is  used  whenever  the  order  of  the  items  carries  a  significance,  such  as 
command  order.  The  user  can  change  which  item  is  selected  by  using  the  mouse  to  select  (click  on) 
another  item.  To  move  up  and  down  the  list  once  the  initial  selection  is  made,  the  directional  arrow 
pick-and-put  buttons  are  employed.  Source  lists  are  structured  in  descending  order.  The  Validate 
button  verifies  that  the  components  are  in  a  logical  and  operationally  sound  execution  order.  The 
Approve  button  verifies  that  the  component  has  been  reviewed  and  is  ready  for  operational  use. 
Response  to  these  functions  could  be  accomplished  with  a  pop-up  response  window.  The  Save  and 
Close  buttons  follow  the  definitions  described  in  the  common  action  buttons  are  utilized  on  this 
window.  The  drag-and-drop  convention  is  an  alternative  method  for  pick-and-put.  A  design 
consideration  of  the  drag-and-drop  convention  is  that  it  may  require  a  substantial  amount  of  coding 
for  some  COTS  tools  to  implement. 
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6.4.7.4  Space  Vehicle  (SV)  Limit  Set  Window 

The  SV  Limit  Set  window  uses  scrollable  lists  to  display  available  and  active  limit  sets.  Only  one 
list  can  have  focus  at  one  time  to  alleviate  confusion.  A  number  is  typed  into  the  expiration  interval 
input  field.  An  option  menu  contains  the  time  span  for  the  expiration  interval.  An  example  is:  a  2  is 
typed  into  the  input  field  and  a  selection  of  ‘days’  is  made  in  the  option  menu.  This  defines  the 
limit  set  to  expire  in  two  days.  To  activate  a  limit  set  the  limit  set  is  selected,  an  expiration  interval 
is  defined,  if  desired,  and  the  Add  to  Available  List  button  is  selected.  This  function  adds  the  limit 
set  to  the  Active  Limit  Set  List.  To  create  a  new  limit  set  the  user  chooses  the  desired  scope  from 
the  option  menu,  and  inputs  the  name  into  the  Limit  Set  Name  input  field  and  activates  the 
Edit/New  button.  If  a  previous  limit  set  is  selected  the  name  appears  in  the  Limit  Set  name  input 
field.  A  limit  set  is  selected  and  the  Edit/New  button  is  activated  to  obtain  the  Edit/New  Limit  set 
window.  The  Import  button  allows  for  limit  sets  from  other  databases  or  systems  to  be  copied  and 
used  for  another  vehicle.  The  Apply,  Edit/New,  Delete  and  Close  common  action  buttons  are 
utilized  on  this  window. 

6.4.7.5  Import  Limit  Set  Window 

The  following  paragraphs  describe  variations  of  conventions  for  creating  import  windows. 

Variation  1:  The  import  limit  set  window  allows  for  limit  sets  from  other  databases  or  systems  to  be 
added  into  a  database.  This  window  is  a  dialog  box  automatically  created  by  the  tool.  Some  tools, 
such  as  UIM/X,  create  basic  dialog  boxes.  The  dialog  contains  basic  functions  but  may  not  allow  the 
developer  to  change  common  features  such  as  color.  The  inability  to  make  changes  to  the  dialog  box 
may  make  the  dialog  box  noncompliant  with  defined  conventions.  There  are  buttons  to  activate 
functions  such  as  OK,  Filter,  Cancel,  and  Help.  One  advantage  of  this  implementation  is  that  the  code 
to  perform  these  functions  is  created  with  the  window. 

Variation  2:  A  window  that  has  the  look  of  a  dialog  box  but  is  created  by  the  user  can  be  edited  by  the 
user.  The  user  is  able  to  change  the  size  of  each  item  and  the  color  combinations.  There  is  an  input 
field  for  file  specification,  scrollable  list  boxes  display  directories  and  the  files  in  the  directories,  and 
a  text  field  to  display  a  selection  made  in  the  scrollable  file  list.  Only  the  most  recently  selected 
directories  are  visible  to  the  user.  There  are  buttons  to  activate  functions  such  as  OK,  Filter,  Cancel, 
and  Help.  To  implement  these  functions  more  coding  is  required. 

6.4.7.6  Edit/New  Limit  Set  Window 

This  window  uses  multiple  input  fields,  an  option  menu,  and  a  push  button  to  define  a  Limit 
set.  The  user  types  in  the  parameter  name  and  the  limits  in  the  input  fields.  An  option  menu 
contains  engineering  unit  selections  defined  for  the  system  to  define  the  parameter.  The 
Add/Update  Parameter  button  is  pressed  when  all  of  these  inputs  are  completed.  A 
scrollable  list  box  displays  the  parameters  defined  for  the  limit  set.  A  sorting  function  for 
the  list  of  limit  parameters  allow  for  organization  by  subsystem.  The  Trend  Set  button 
accesses  the  trending  windows.  The  Save,  Delete,  Clear,  and  Close  buttons  follow  the 
definitions  in  Table  4.1,  Common  Button  Actions. 
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6.4.7.7  SV  Trending  Set  Window 

The  Trending  Set  window  uses  scrollable  list  boxes  to  display  the  available  and  active  trending  sets. 
An  input  field  is  available  to  display  the  selected  trend  set  or  to  input  a  new  trend  set.  A  time  interval 
is  defined  by  the  day,  month,  year,  hour,  and  duration  input  fields.  The  order  of  these  items  can  be 
changed.  For  example,  some  operations  rooms  prefer  month,  day,  year.  The  duration  input  field 
accepts  numeric  data  and  the  time  span  is  selected  from  the  option  menu  (hours,  days,  weeks,  etc.). 
There  are  push  buttons  to  access  the  edit  window,  delete  a  trending  set,  import  a  trending  set,  or 
cancel  the  function.  The  Limit  Set  Scope  default  to  the  Vehicle,  with  the  IRON  input  field  (added  to 
the  window)  is  left  blank.  Permanent  data,  such  as  default  trend  sets,  can  be  specified  by  the  system 
as  not  available  for  deletion.  The  function  to  delete  permanent  data  can  be  identified  with  a  pop-up 
window  and  a  message  stating  that  the  data  cannot  be  deleted. 

6.4.7.8  Telemetry/Trending  Playback  Window 

This  window  utilizes  toggle  buttons  to  specify  the  type  of  playback:  trending  or  telemetry.  Automatic 
Data  selection  convention  is  utilized.  The  IRON  from  the  File  Set  selection  window  is  identified  and 
placed  into  the  IRON  input  text  field  by  the  system.  The  user  can  still  type  an  IRON  into  the  IRON 
input  field.  An  input  text  field  allows  the  user  to  define  the  date  of  the  desired  playback  data.  Radio 
buttons  are  used  to  select  the  report  type.  The  ‘None’  button  behaves  like  a  toggle  button;  when  it  is 
selected  all  other  buttons  are  de-selected.  The  ‘Commanding’,  ‘Telemetry’,  and  ‘Trending’  buttons 
act  as  radio  buttons,  one  or  more  can  be  selected  at  one  time.  The  raw  telemetry  data  can  be  processed 
utilizing  different  limit  and  trend  sets.  The  limit  and  trend  sets  have  default  values  but  can  be  changed 
by  the  user.  The  playback  rate  processes  the  data  at  different  rates  ranging  from  one  half  of  real  time 
to  twice  the  speed  of  real  time.  Buttons  are  used  to  activate  the  process  or  to  cancel  the  function. 

6.4.7.9  Block  Command  Maintenance  Window 

A  scrollable  list  box  is  used  to  select  the  block  command  the  user  wants  to  edit.  There  is  a  text  field  to 
input  a  new  block  command  or  display  the  selected  block  command.  Push  buttons  are  used  to  activate 
the  Edit,  Delete  and  Close  functions. 

6.4.7.10  SSP  Main  Window 

A  scrollable  list  box  is  used  to  select  the  SSP  the  user  wants  to  edit.  A  text  input  field  is  used  to  input 
a  new  SSP  description.  This  input  field  is  also  used  to  view  or  to  edit  the  current  description  of  the 
selected  SSP.  The  Save  Description  button  allows  the  updated  description  to  be  stored  on  the  system. 
A  text  input  field  is  available  to  type  in  a  new  SSP  name  or  to  display  the  selected  SSP.  Import,  Edit, 
Delete,  and  Cancel  capabilities  are  accessible  by  a  button. 

6.4.7.11  SSP  Components  Window 

Common  command  and  directive  combinations  can  be  placed  into  a  component.  This  allows  for  these 
combinations  to  be  added  to  an  SSP  as  a  whole  instead  of  many  small  parts.  The  component  is  paid  of 
a  concept  of  creating  SSPs  in  a  modular  format.  Three  scrollable  list  boxes  display  the  items  in  the 
component,  available  commands,  and  available  directives.  The  pick-and-put  method  is  utilized  to 
move  data  items  for  component  creation  or  editing  a  component.  Push  buttons  are  used  to  activate  the 
validate  and  approve  functions.  The  Validate  button  verifies  that  the  component  items  are  in  a  logical 
and  operationally  sound  execution  order.  The  Approve  button  verifies  that  the  component  has  been 
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received  and  is  ready  for  operational  use.  Push  buttons  are  used  to  Close  the  window  and  to  Save  the 
updated  component. 

6.4.7.12  Derived  Telemetry  Window 

A  derived  telemetry  point  is  a  parameter  that  uses  different  bits  in  the  wavetrain  to  create  a  parameter 
not  defined  in  the  wavetrain.  This  window  uses  toggle  buttons  to  define  the  scope  of  the  parameter. 

An  option  menu  contains  a  list  of  derived  telemetry  points.  Spin  boxes  are  used  to  select  a  wavetrain 
and  a  parameter  type.  There  are  option  menus  to  select  the  parameter  bit  length  and  algorithm  used  to 
create  the  derived  parameter.  Input  fields  are  used  for  the  input  parameters  that  define  the  wavetrain 
word  used  to  define  derived  telemetry  point.  The  OK,  Apply,  Delete,  and  Close  buttons  follow  the 
definitions  described  in  Table  4.1,  Common  Button  Actions. 

6.4.7.13  Match/Set  Bits  Window 

This  window  uses  option  menus  and  input  fields  to  define  the  parameter  bits  that  create  the  derived 
parameter  bits.  The  window  repeats  the  inputs  8  times  to  define  8  bit  positions.  Because  most 
parameters  are  defined  in  multiples  of  8,  the  Next  8  Bits  button  allows  access  to  another  version  of 
the  window.  The  difference  is  that  the  next  display  defines  bits  9-16.  Consecutive  windows  are 
accessed  depending  on  the  size  of  the  parameter  defined  on  the  Derived  Telemetry  window.  The  OK, 
Apply,  and  Cancel  buttons  follow  the  definitions  of  the  Common  Button  Actions  described  in  Para. 
4.2. 3. 5. 5,  Common  Action  Buttons. 

6.5  Satellite  Mission  Payload  Operations  Conventions 

6.5.1  Description 

The  tasks  required  to  perform  Mission  Payload  Operations  include  data  receipt,  processing,  analysis, 
and  dissemination.  Although  the  processing  and  analysis  functions  relate  primarily  to  the  mission  data 
itself,  unique  display  requirements  may  also  exist  for  monitoring  and  controlling  payload  sensors  and 
on-board  processes.  Because  both  of  these  areas  are  highly  mission  unique,  the  intent  of  this  section  is 
to  identify  conventions  that  are  common  among  programs  and  can  be  applied  to  all  equally.  The 
conventions  associated  with  this  domain  are  therefore  at  a  higher  level  than  the  other  domains.  For 
most  functionality,  the  conventions  already  defined  are  sufficient.  Another  rationale  for  the  high  level 
of  this  domain  is  the  uniqueness  of  the  payloads  themselves.  Examples  of  different  types  of  payloads 
that  would  need  to  be  supported  are:  Navigation,  Communications,  Weather,  and  Surveillance.  The 
conventions  captured  for  this  document  reflect  the  review  of  payload  operations’  screens  from  GPS, 
DSCS,  and  SBIRS. 

6.5.2  Screen  Layout 

Described  below  is  screen  layout  information  regarding  arrangement  of  windows  and  navigation, 
rules  on  overlapping  windows,  as  well  as  definitions  and  handling  criteria  for  critical  information. 

6.5.2. 1  Arrangement  of  Windows  and  Navigation 

Arrangement  of  windows  and  navigation  utilize  the  high-level  conventions  described  in  Para.  2, 
Operator  Interaction,  and  Para.  4,  Windows.  However,  unique  requirements  of  a  specific  payload 
necessitate  that  each  program  determines  the  low-level  requirements. 
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Those  windows  containing  critical  information  should  not  be  allowed  to  be  made  into  icons.  Each 
satellite  program  needs  to  identify  “critical  data”  and  restrict  the  appropriate  windows  from  being 
iconified.  Windows  that  do  not  contain  critical  information  can  be  iconified,  as  determined  by  the 
individual  satellite  program. 

Shortcut  keys  are  available  for  frequently  used  functions.  (See  Para.  2.3,  Navigation  Keys  and 
Techniques).  The  following  is  one  example  specific  to  Mission  Payload: 

Build  Upload:  Payload  specialists  in  a  satellite  program  like  GPS  need  to  be  able  to  make  corrections 
to  on-board  data  and  processes  quickly.  Having  a  function  key  or  “hot  key”  that  allows  instant  access 
to  the  screens  required  to  build  an  upload  to  a  specific  satellite  is  desirable.  This  key  could  be 
available  from  Payload  Operations,  Contact  Operations  or  Engineering  Analysis,  depending  on 
program  requirements. 

6. 5.2.2  Rules  on  Overlapping  Windows 

For  the  following  reasons,  a  non-overlapping  or  tiled  convention  for  window  placement  is 
recommended  in  the  Payload  Operations  domain: 

•  Payload  Operations  is  a  real-time  domain  that  frequently  requires  more  than  one  window  be 
opened  for  simultaneous  viewing. 

•  Timeliness  of  operator  actions  also  requires  that  operator  window  manipulation  or  placement 
be  reduced  or  eliminated. 

•  Operator  screen  management  and  extra  steps  are  typical  of  overlapping  or  cascaded  windows. 

This  design  convention  does  allow  for  dialog  and  feedback  windows  to  appeal-  on  top  of  (or 
overlapping)  the  current  window  when  an  operator  action  is  required  prior  to  leaving  the  window  or 
continuing  to  the  next  step. 

6.5.2.3  Definition  and  Handling  of  Critical  Information 

Critical  information  in  mission  payload  operations  can  include  anything  that  prevents  the  mission 
from  being  accomplished  or  which  poses  a  danger  to  personnel.  Some  examples  are:  satellite 
anomalies,  ground  anomalies,  communication  outages,  degradations  or  failures  related  to  the  payload 
mission,  fire  alarms,  emergency  messages,  and  so  forth.  As  described  in  the  Para.  3. 1.3.2,  Alert  Area, 
critical  information  is  color-coded  and  may  be  accompanied  by  an  audible  notification,  appear  in  a 
dialog  window  or  may  be  displayed  in  the  alert  area  as  a  message.  Operator  notification  of  critical 
data  requires  operator  action/acknowledgment. 

6.5.3  Header  Zone 

The  header  zone  for  Mission  Payload  Operations  utilizes  the  conventions  as  described  in 
Para.  3.E2,  Header  Zone. 
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6.5.4  Status  Zone 


Emphasis  is  concentrated  on  reducing  the  size  of  the  status  zone  as  much  as  possible,  allowing  the 
most  workspace  possible.  The  section  below  describes  Mission  Payload  Operations  specific  status 
area  and  alert  area  conventions. 

6.5.4.1  Status  Area 

Content  requirements  are  mission  unique  and  are  determined  by  each  satellite  program.  Examples  of 
data  relevant  to  this  area  includes:  Constellation  Status,  Payload  Status,  Ground  System  Status,  Data 
Quality,  and  OPS  CAP.  The  components  that  comprise  the  Mission  Payload  Operations  Status  Area 
should  be  clearly  labeled  to  identify  the  data  presented. 

6. 5.4.2  Alert  and  Message  Area 

The  alert  and  message  area  follows  the  conventions  described  in  Para.  3. 1.3. 2,  Alert  Area.  Specific 
alerts  for  Mission  Payload  are  mission  unique  and  are  supplied  by  the  individual  program.  Examples 
of  possible  Payload  Operations  alerts  are  in  Table  6.9.  Contents  of  the  ‘Source’  column  may  include: 
IRON,  flight  number,  equipment  name,  external  user,  launch  number,  process  ID,  etc. 

Table  6.9.  Mission  Payload  Operations  Alert  Examples 


Criticality 

Date/Time 

Source 

Text 

A 

194/00:39:26 

xxxx 

Loss  of  signal  from  Sensor  C 

A 

194/00:42:31 

1234 

Guam-B  down  for  maintenance 

W 

194/00:41:32 

mi 

Sensor  B  temp  out  of  limits 

E 

194:01:05:41 

2222 

Upload  complete 

6.5.5  Toolbar 

Toolbar  placement  can  be  either  below  the  status  zone  or  at  the  bottom  of  the  screen  (care  must  be 
taken  to  choose  a  location  which  avoids  a  situation  in  which  critical  data  is  covered  by  the  toolbar 
menus  when  open). 

Listed  below  are  the  Mission  Payload  specific  conventions  that  apply  to  menu  items  in  the  toolbar: 

•  File  -  To  include  save,  save  as  (as  required)  print  and  exit 

•  Payload  -  To  include  Mission  Operations,  Payload  Operations,  and  Playback 

•  Analysis  -  Screens  and  software  packages  required  to  perform  Mission  and  Payload 
Operations  by  a  particular  program  to  include  histograms,  trending  graphs,  and  alert  history. 

•  Reports  -  Forms,  logs,  reports  and  history  files  required  by  a  Program 

•  Help  -  General  help  for  Mission/Payload  Operations. 


72 


6.5.6  Mission  Payload  Specific  Conventions 

Mission  Payload  specific  conventions  are  mission  unique  and  are  identified  by  each  satellite  program. 

6.5.7  Mission  Payload  Windows 

Described  below  are  conventions  specific  to  Mission  Payload  windows. 

6.5.7.1  Multi-Payload  Window 

A  hierarchical  tree  structure  is  used  to  provide  a  high-level  status  display  for  payload  components. 
Payload  Selection  is  available  from  toolbar,  if  not  defaulted  by  sign-on  sequence.  Conventions  for 
indicating  status  on  buttons,  as  described  in  Para  3.2.1,  Usage  of  Screen  Colors,  are  followed.  The 
widget  used  for  this  example  is  an  on-line  system  button  using  a  combination  of  border  color  and  fill 
to  represent  the  status  of  the  system. 

6. 5.7.2  SV  Memory  Status 

This  window  provides  status  of  the  contents  of  a  specific  SV’s  central  processing  unit  (CPU)  and 
memory.  Widgets  used  for  this  example  include  the  following:  a  single  line  title  bar,  scrollable  list 
boxes  to  easily  access  desired  memory  address  locations,  and  a  spinner  box  to  select  the  CPU  desired. 

6.5.7.3  Payload  Status  Window 

The  Payload  Status  Window  is  an  example  of  how  to  display  the  status  of  an  SV’s  payload 
subsystem.  Payload  Status  is  available  from  toolbar,  Contact  Operations,  or  Engineering  Analysis. 

The  following  are  examples  of  Mission  Payload  Operations  specific  implementations  of  conventions 
which  can  be  used  in  this  window:  two  line  title  Bar  (used  as  an  example  to  display  the  type  of 
contact  and  still  have  room  for  site,  time  SV,  etc.  without  getting  cluttered).  This  is  an  example  of 
output  fields  using  a  combination  of  border  color  and  fill  to  indicate  status,  a  scrollable  table,  and 
navigation  push  buttons.  The  scrollable  table  allows  for  easy  access  to  telemetry  data  for  large 
subsystems  where  the  data  does  not  fit  on  one  screen.  The  navigation  push  button  provides  access  to  a 
schematic  diagram  of  the  subsystem  for  analysis. 

6. 5.7.4  Mission  Operations  Window 

The  Mission  Operations  window  is  a  placeholder  for  a  Main  Mission  Operations  screen  that  would  be 
used  as  a  default  screen  for  Mission  Operators.  Windows  are  to  be  provided  by  each  Satellite 
Program. 

6. 5.7.5  Mission  Payload  Tasking  Window 

The  Mission  Payload  Tasking  Window  is  an  example  of  a  window  used  to  display  a  daily  schedule  of 
tasks  required  for  a  payload  specialist.  The  tasking  window  is  available  from  the  toolbar.  Examples  of 
Mission  Payload  Operations  specific  implementations  of  conventions  which  can  be  used  in  this 
window  are  as  follows:  single  line  title  bar  (used  to  show  an  example  of  a  one -line  title  bar,  two-line 
title  bars  can  be  used  when  you  have  a  lot  of  information  to  convey  and  do  not  want  it  to  be 
cluttered),  check  buttons  used  by  the  operator  as  a  means  of  filtering  a  schedule  of  daily  tasks,  and  a 
scrollable  list  box  used  to  display  the  schedule  of  tasks. 
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6. 5. 7.6  Build  Payload  Upload  Window 

This  window  represents  an  example  of  a  Build  Upload  screen  that  may  be  used  by  a  program  to 
upload  payload  specific  data  to  a  satellite.  Build  Payload  Upload  is  available  from  the  toolbar  and 
from  Contact  Operations.  Listed  below  are  examples  of  possible  Mission  Payload  Operations  specific 
implementations  of  conventions  which  can  be  used  in  this  window:  a  scrolled  list  is  used  to  select  the 
SV  of  interest,  radio  buttons  are  used  to  select  the  upload  type,  and  input  fields  are  used  to  request 
upload  start  time  and  span  of  upload. 

As  an  option,  this  window  can  include  a  command  dialog  used  in  conjunction  with  command  line 
entry  field  (see  Para  6.1.7.12,  Commanding  Window). 

6. 5.7.7  Schematic  Diagram 

This  window  is  provided  as  an  example  of  how  to  display  schematic  diagrams.  The  only  widget 
shown  is  a  scrolled  window,  used  to  accommodate  displaying  large  diagrams  on  a  single  screen. 

6.6  Satellite  Operations  Support  Conventions 

6.6.1  Description 

Operations  Support  includes  functions  which  are  required  to  maintain  operations  but  which  are  not 
directly  related  to  operational  control  of  satellites.  The  areas  included  in  this  domain  are  System 
Administration,  Security  Management,  Database  Management,  and  Training/Simulation  for  satellite 
operations.  Each  of  these  are  described  in  the  sections  below. 

6. 6.1.1  System  Administration 

Listed  below  are  the  Operations  Support  specific  functions  that  apply  to  System 
Administration: 

•  The  System  Administration  windows  follow  COTS  tool  conventions.  All  system 
administration  windows  were  derived  from  the  system  administration  tools  delivered  with  the 
operating  systems  for  the  following  companies:  International  Business  Machine  (IBM),  Sun, 
Hewlett  Packard  (HP)  and  Digital  Equipment  Corporation  (DEC). 

•  A  high  level  analysis  was  performed  on  each  tool’s  functionality  and  GUI  techniques  were 
analyzed.  A  detailed  COTS  trade  study  was  not  performed.  Listed  below  are  the  comparable 
COTS  Tools: 

a)  IBM’s  Advanced  Interactive  Executive  (AIX)  -  Uses  toggle  buttons  for  all  windows, 
while  utilizing  a  drill-down  capability.  A  drill-down  capability  requires  the  user  to  open 
one  window  to  get  to  another  window.  IBM’s  AIX  uses  limited  graphics,  provides  lots  of 
functionality,  but  as  a  result  of  the  drill-down  capability,  requires  lots  of  windows.  The 
GUI  in  this  tool  is  average. 

b)  Sun’s  Solaris  -  Uses  icon/push  buttons  for  the  main  window,  with  some  drill-down,  and 
limited  use  of  graphics.  Additional  functionality  is  available  with  purchase/add-on  of 
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additional  Solaris  tools.  The  GUI  in  this  tool  is  good. 

c)  HP’s  Unix  (UX)  -  Uses  icon/push  buttons  for  the  main  window,  with  some  drill-down,  and 
limited  use  of  graphics.  No  information  available,  at  this  time,  on  functionality.  The  GUI  in 
this  tool  is  good. 

d)  DEC-  Uses  icon/push  buttons  for  main  window.  The  tool  that  comes  with  the  operating 
system  has  limited  functionality.  DEC  utilizes  combo  boxes/drop  down  menus,  and  as  a 
result,  minimizes  the  number  of  windows  required  to  perform  a  particular  function.  The 
GUI  in  this  tool  is  very  good. 

6. 6.1. 2  Security  Administration 

Listed  below  are  the  Operations  Support  specific  functions  that  apply  to  security 
administration: 

•  The  security  administration  windows  follow  COTS  tools  conventions  and  are  derived  from 
COTS  products,  as  well  as  specialty  COTS  security  tools. 

•  All  security  administration  windows  meet  all  the  functionality  of  the  system  administration 
tools  analyzed;  however,  they  may  not  meet  all  the  functionality  for  specialty  security  tools. 

6. 6.1. 3  Database  Administration 

Listed  below  are  the  Operations  Support  specific  functions  that  apply  to  database 
administration: 

The  domain  team  performed  a  high-level  analysis  on  several  COTS  databases  to  include:  Oracle, 
Sybase,  and  Microsoft  (MS)  Access.  The  results  of  this  analysis  determined  that  the  database 
products  have  built-in  tools  that  meet  the  functionality  of  the  HMI  Functional  Task  Analysis. 
Therefore,  focus  was  placed  on  unique  satellite  database  requirements  to  include:  problem 
tracking/reporting,  and  certain  utility  functions  that  can  be  used  to  modify  database  options. 

6.6. 1.4  Training/Simulation 

Listed  below  are  the  Operations  Support  specific  functions  that  apply  to 
training/simulation: 

•  The  training/simulation  function  under  Operations  Support  focuses  on  the  windows  to  be 
used  by  the  trainer.  The  student/trainee  would  use  the  same  windows  and  thus  the  same 
conventions  as  the  domain  for  which  they  are  training  (e.g.,  Contact  Operations). 

•  A  tab  convention  is  used  in  the  design  of  the  training  windows  to  combine  the  Plan  Sim,  Run 
Sim,  Playback  Sim,  and  Update  Student  Database  functions.  As  a  result,  the  number  of 
windows  is  transparent  to  the  user,  and  appears  to  be  minimized. 


75 


6.6.2  Screen  Layout 

Described  below  is  screen  layout  information  regarding  arrangement  of  windows  and  navigation, 
rules  on  overlapping  windows,  as  well  as  definitions  and  handling  criteria  for  critical  information. 

6.6.2. 1  Arrangement  of  Windows  and  Navigation 

Listed  below  are  the  Operations  Support  specific  conventions  that  apply  to  the 
arrangement  of  windows: 

•  Operations  support  is  not  a  real-time  activity.  As  a  result,  window  layout  is  more  flexible  and 
overlapping  as  well  as  resizing  of  windows  is  allowed. 

•  The  ability  to  access  network  activities  whenever  possible  for  ah  functions  has  been  and 
should  be  incorporated. 

•  Shortcut  keys  are  to  be  available  for  frequently  used  functions.  See  Para.  2.3,  Navigation 
Keys  and  Techniques,  for  shortcut  key  examples.  At  this  time,  there  are  no  Operations 
Support  specific  shortcut  keys. 

6.6.2.2  Rules  on  Overlapping  Windows 

Operations  Support  is  not  directly  involved  with  real-time  data  management,  therefore  window 
overlapping  (cascading  of  windows)  is  allowed.  Refer  to  Para.  2.5,  Use  of  Multiple  Windows  on  a 
Single  Screen  Display. 

6.6.2.3  Definition  and  Handling  of  Critical  Information 

The  operations  support  domain  does  not  have  any  specific  critical  data  requirements  and  uses 
conventions  described  in  Para.  3. 1.3. 2,  Alert  Area. 

6.6.3  Header  Zone 

The  header  zone  for  Operations  Support  utilizes  the  conventions  as  described  in  Para.  3.1.2,  Header 
Zone. 

6.6.4  Status  Zone 

The  Operations  Support  function  may  require  multiple  windows  to  be  open  simultaneously. 
Consequently,  this  domain  requires  a  smaller  status  area  and  larger  work  zone.  The  section  below 
describes  Operations  Support  specific  status  area  and  alert  area  conventions. 

6.6.4.1  Status  Area 

The  following  components  are  examples  of  the  content  that  could  be  displayed  in  the 
status  area. 
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6.6.4.1.1  Activities  Scheduled 


A  schedule  of  activities  may  not  be  necessary  for  system,  security,  and  database  administration 
operations;  however,  a  schedule  of  activities  is  an  alternative,  if  needed.  A  training  activity  schedule 
could  be  included  in  the  status  area,  and  would  follow  the  conventions  defined  in  the  Contact 
Operations  domain. 

6.6.4.1.2  Resource  and  Activity  Status 

The  following  are  two  alternatives  for  providing  resource  and  activity  status: 

Alternative  1  -  Use  of  hierarchical  icons.  Using  hierarchical  icons  would  provide  a  more  accessible 
option  to  selected/defined  areas  of  importance.  An  example  of  functions  that  could  be  accessed  via 
icons  includes:  Problem  Analysis/  Tracking,  Network  and  Security. 

Alternative  2  -  Use  of  graphics  or  lists.  A  graphical  format  would  provide  more  visual,  and 
consequently  more  efficient  analysis  capability.  A  variation  is  to  provide  system/process  information 
in  a  list  format  that  allows  for  more  status  in  the  space  provided  (as  opposed  to  graphical  format). 

6. 6.4.2  Alert  and  Message  Area 

The  alert  and  message  area  follows  conventions  described  in  Para.  3. 1.3.2,  Alert  Area.  Content  of 
alerts  and  messages  can  include:  security  alarms,  hardware/software  problems/updates,  networking 
problems/updates,  database  problems/updates  and  system  feedback.  Table  6.10  includes  examples  of 
alarms,  warnings,  and  events. 

Table  6.10.  Operations  Support  Alarms,  Warnings,  and  Event  Examples 


Criticality 

Date/Time 

Source 

Text 

E 

149/00:23:00 

system 

Password  for  user  'smith'  added 

E 

149/00:20:00 

system 

User  'smith'  created 

E 

149/00:19:00 

system 

Backing  up  filesystem  '/usr' 

A 

149/00:18:00 

system 

Security  Alert 

6.6.5  Toolbar 

Listed  below  are  the  Operations  Support  specific  conventions  that  apply  to  toolbars: 

•  The  toolbar  location  is  not  critical:  it  can  be  placed  below  the  header  bar  and  above  the  status 
area,  below  the  status  area,  or  at  the  bottom  of  the  screen.  The  toolbar  includes  a  pull-down 
menu  to  be  used  for  navigation  or  entry  point  into  the  operations  support  functions.  There  is 
no  operational  reason  to  prevent  the  pull-down  menu  from  temporarily  covering  the  status 
area  if  an  option  is  chosen  which  does  so  (first  case). 

•  The  toolbar  includes  the  functionality  to  select  one  of  the  following  options:  File,  System 
Administration,  Security,  Database  and  Training/Simulation  using  a  ‘file  menu’  approach. 

a)  The  File  option  includes  access  to  system  functions  such  as  system  prompt,  print,  and 
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exit.  The  system  prompt  option  is  to  provide  a  system  window  for  command  line  entry. 
The  print  option  is  to  provide  a  mechanism  for  printing  the  work  zone  (header  and  all 
windows)  or  a  specific  window.  The  exit  option  is  to  exit  the  operations  support  area. 

b)  The  System  Administration  option  acts  as  an  entry  point  into  the  system  administration 
specific  functions  to  include  the  following  options:  Main  Sys  Admin,  SW  Mgmt,  HWw 
Mgmt,  Security,  User  Mgmt,  Network  Mgmt,  Storage  Mgmt,  Problem  Mgmt,  Performance 
Mgmt,  Printer  Mgmt,  Processes  Mgmt,  Backup/Restore  and  Shutdown. 

c)  The  Security  option  provides  an  entry  point  into  the  security  administration  specific 
functions  to  include  the  following  options:  C2  (a  level  of  DoD  security)  Audit,  Alarm 
Monitoring,  Firewall  Configuration,  Guardwall  Configuration. 

d)  The  Database  option  provides  an  entry  point  into  database  management  specific  functions 
to  include  the  following:  Database  (COTS  Product),  Utilities  and  Problem 
Tracking/Reporting. 

e)  The  Training/Simulation  option  provides  an  entry  point  into  the  training/simulation 
specific  functions,  to  include  the  following  options:  Plan  Sim,  Run  Sim,  Playback  Sim, 
and  Update  Student  Database. 

f)  The  Help  option  provides  application  level  help  for  all  of  operations  support. 

•  For  all  domains,  it  is  important  to  setup  user  limitations  based  on  the  operations  concept. 
Therefore,  depending  on  how  ‘user  permissions’  are  set  up,  different  functions  of  the 
Operations  Support  toolbar  may  be  grayed  out  (insensitive)  if  the  user  does  not  have  access. 

6.6.6  Operations  Support  Specific  Conventions 

All  system  and  security  administration  windows  need  access  to  a  system  prompt  feature  (under  the 
file  menu  option)  which  when  activated,  displays  a  system  prompt  area  (scrollable  multiple  line  input 
field)  at  the  bottom  of  the  window. 

In  order  to  minimize  potential  operator  error,  for  all  windows  (to  include  child  windows),  it  is  a 
preferred  convention  to  use  combo  boxes,  instead  of  input  fields.  This  convention  allows  an  operator 
to  either  select  or  type  an  option  minimizing  the  potential  for  operator  error.  In  addition,  whenever 
possible,  menus  (file  option,  drop  down,  etc.)  are  used  instead  of  push  buttons.  These  GUI  techniques 
maximize  functionality  while  minimizing  the  number  of  windows  required  to  perform  a  particular 
task.  As  a  result,  this  convention  is  beneficial  to  both  a  novice  and  an  expert  user. 

There  are  no  Operations  Support  specific  conventions  for  the  database  and  Paining  windows.  The 
Operations  Support  domain  utilizes  the  conventions  described  in  Para.  1,  Overview,  through  Para.  5, 
Help. 
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6.6.7  Operations  Support  Windows 

6. 6.7.1  System  Administration  Windows 

Listed  below  are  the  Operations  Support  specific  functions  that  apply  to  System  Administration. 

6. 6.7.1. 1  System  Administration  Main  Window  Variation  1,  Variation  2,  Variation  3, 
Variation  4 

Listed  below  are  the  specific  functions  that  apply  to  the  System  Administration  main  window: 

•  There  are  four  views  within  this  window.  The  default  view  is  accomplished  using  icons  and 
labels;  however,  a  view  exists  for  icons  only,  labels  only,  and  one  using  toggle  buttons  (GUI 
very  similar  to  the  IBM  tool).  Therefore,  Main  System  Administration,  Alternative  views  1, 

2,  3,  and  4  should  all  be  tied  to  one  window  with  the  preferred  view  being  displayed  based  on 
operator  preference.  Under  the  view  menu  option,  the  operator  can  choose  the  display  option 
for  the  window  view  selected. 

•  These  windows  can  be  used  as  a  type  of  menu/navigation  area  for  the  key  functions  within 
system  administration.  The  functionality  of  these  windows  is  based  on  IBM’s  tool.  The  GUI 
conventions  are  based  on  a  combination  of  the  Sun  and  HP  tools.  The  windows  provide  the 
ability  to  select  any  of  the  following  functions:  Main  Sys  Admin,  SW  Mgmt,  HW  Mgmt, 
Security,  User  Mgmt,  Network  Mgmt,  Storage  Mgmt,  Problem  Mgmt,  Performance  Mgmt, 
Printer  Mgmt,  Process  Mgmt,  Backup/Restore,  and  Shutdown.  A  system  prompt  option 
(using  Scrollable  List)  is  also  provided 

•  This  design  maximizes  the  number  of  windows,  but  information  is  presented  in  a  simple  well- 
organized  manner.  User  performance  may  be  improved  because  of  the  orderly  and  clutter-free 
appearance.  From  a  convention,  as  well  as  GUI  technique  perspective,  the  System 
Administration  Variation  1,  2,  3,  and  4  windows  are  preferred  over  the  System 
Administration  Variation  5  window. 

6. 6.7.1. 2  System  Administration  Main  Window  Variation  5 

The  design  for  this  window  includes  all  of  the  functionality  included  in  the  previous  System 
Administration  windows.  However,  from  a  GUI  perspective,  this  window  uses  a  file  menu  only 
option.  This  convention  minimizes  real  estate  by  providing  cascading  menu  options,  which  minimizes 
the  number  of  windows  the  operator  must  access  to  perform  a  task. 

6.6.7.1.3  SW  Mgmt  Variation  1  Window,  HW  Mgmt  Variation  1  Window,  User 
Management  Window  Variation  1,  Users  Window 

These  windows  can  be  used  as  a  menu/navigation  area  for  the  key  areas.  The  functionality  for  these 
windows  is  based  on  IBM’s  tool.  They  use  push  buttons,  which  provide  a  drill-down  capability  to  get 
to  the  required  function.  This  design  maximizes  the  number  of  windows,  but  information  is  presented 
in  a  simple  and  well-organized  manner.  User  performance  may  be  improved  because  of  the  orderly 
and  clutter-free  appearance. 
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6.6.7.1.4  SW  Mgmt  Variation  2  Window,  HW  Mgmt  Variation  2  Window 

This  variation  minimizes  real  estate  and  the  number  of  windows  that  an  operator  must  access  while 
providing  immediate  status.  For  this  reason  from  a  convention,  as  well  as  GUI  technique  perspective, 
the  SW  and  HW  Mgmt  Variation  2  windows  are  preferred  over  SW  and  HW  Variation  1  windows. 
These  windows  can  be  used  as  a  menu/navigation  area  for  the  key  functions.  The  windows  display 
status  by  using  drop  down  menus,  file  menus,  and  push  buttons.  This  is  a  little  different  than  the 
COTS  tools  in  that  it  incorporates  the  following  functions  into  one  window:  List  Software, 
Install/Update  Software,  Modify  Software,  Client  Software  Management,  Database  Management,  and 
Configuration  Management.  As  a  result,  the  number  of  windows  required  for  the  function  is  reduced. 

6. 6.7.1 .5  Add  a  User  Window,  Password  Window 

These  windows  use  input  fields  and  combo  boxes  to  allow  the  user  to  select  and/or  set  default 
information.  A  submit  button  is  used  to  apply  and  process  the  updates.  This  design  minimizes  real 
estate,  the  number  of  windows  that  an  operator  must  access  to  perform  a  task,  and  minimizes  operator 
eiTors. 

6. 6.7.1. 6  User  Management  Variation  2  Window,  Modify  Groups  Window 

These  windows  use  combo  boxes,  input  fields,  toggle  buttons,  and  push  buttons  to  allow  the  user  to 
select  and/or  set  default  information.  The  functionality,  as  well  as  GUI  convention,  is  modeled  after 
the  DEC  tool.  The  design  combines  several  functions  into  one  window  thus  reducing  the  number  of 
windows.  As  a  result,  these  windows  have  more  options/functions  than  push-button-only  windows. 
This  design  minimizes  real  estate  through  reuse  while  maximizing  efficiency  of  windows  and 
operator  actions.  From  a  convention,  as  well  as  GUI  technique  perspective,  the  User  Management 
Variation  2  window  is  preferred  over  User  Management  Variation  1  window. 

6.6.7.1 .7  Secondary  Groups  Window 

This  window  uses  scrollable  lists  and  push  buttons  to  allow  the  user  to  add/remove  users  from  a 
selected  group.  The  scrollable  lists  provide  the  flexibility  of  viewing  all  the  groups  without  having  to 
open  a  secondary  window.  An  Add/Remove  push  button  is  used  to  add  a  group  to  the  specified  users’ 
profile.  The  functionality  for  this  window  was  modeled  after  the  DEC  tool.  This  design  presents 
information  in  a  simple  and  well-organized  manner.  It  minimizes  the  number  of  actions  that  an 
operator  must  perform  thus  reducing  the  chance  of  operator  error. 

6. 6.7.1 .8  Network  Management  Window 

The  Network  Management  window  is  designed  using  radio  buttons,  as  well  as  file  menu  (for  fast 
path).  The  functions  are  consistent  with  the  COTS  tools,  but  the  GUI  conventions  are  different.  This 
design  combines  several  network  management  functions  into  one  window,  and  minimizes  the  size  of 
windows  while  providing  the  maximum  amount  of  functionality. 

6. 6.7.1. 9  Storage  Management  Window 

The  Storage  Management  window  is  designed  using  a  drop  down  menu  arrow.  The  functions  are 
based  on  the  IBM  tool.  As  a  function  (menu  option)  is  selected,  a  list  box  appears  within  the  window 
detailing  additional  options/functions,  rather  than  a  drill-down  capability  (additional  windows).  This 
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design  combines  several  functions  into  one  window,  and  minimizes  the  size  of  the  window  while 
providing  the  maximum  amount  of  functionality.  In  addition,  the  data  is  organized  in  an  orderly 
manner  with  a  clutter-free  appearance. 

6. 6.7.1 .1 0  Problem  Management  Window 

This  window  is  built  using  the  same  type  of  design  as  the  storage  management  window.  However, 
instead  of  selecting  the  arrow  box,  the  text  would  be  selected  (pull-down  menu).  This  window 
combines  two  Problem  Management  areas,  analysis  and  tracking,  in  order  to  minimize  the  number  of 
windows  required  to  get  into  any  one  problem  management  area.  This  design  provides  more  efficient 
use  of  window  real  estate,  smaller  window  size,  and  a  maximum  amount  of  data  in  the  window.  As  a 
result,  the  data  is  organized  in  an  orderly  manner  with  a  clutter-free  appearance.  From  a  convention, 
as  well  as  GUI  technique  perspective,  this  window  is  preferred  over  Problem  Management  Toggle 
Button  Approach  Window. 

6.6.7.1.11  Problem  Management  Toggle  Button  Approach  Window 

This  window  contains  the  same  functions  as  the  problem  management  window.  However,  the  window 
uses  a  variation  in  GUI  conventions.  Instead  of  using  pull-down  menu,  it  uses  toggle  buttons.  This 
design  maximizes  the  number  of  windows,  but  information  is  presented  in  a  simple,  well-organized 
manner.  Because  the  data  is  organized  in  an  orderly  clutter-free  format,  user  performance  can  be 
improved. 

6. 6.7.1 .12  Performance  Management  Window 

This  window  is  built  using  a  push  button,  toggle  button,  and  combo  box  design.  The  functionality  is 
based  on  the  IBM  tool,  but  the  GUI  conventions  are  different.  Two  areas,  system  and  network,  are 
combined  to  minimize  the  number  of  windows  that  the  user  would  have  to  select.  This  design 
presents  information  in  a  simple  and  well-organized  manner,  which  enhances  pointer  and  eye 
movement  requirements  and  minimizes  operator  error. 

6.6.7.1.13  Print  Management  Window 

This  window  was  designed  to  utilize  both  radio  buttons  and  combo  boxes.  The  functionality  is  based 
on  the  IBM  tool,  but  the  GUI  conventions  are  different.  This  window  combines  three  print 
management  areas  (print  jobs,  printer  characteristics  and  troubleshooting),  again  to  minimize  the 
number  of  windows  required  to  perform  a  particular  print  management  task.  This  design  minimizes 
real  estate  and  the  number  of  windows  that  an  operator  must  access  to  perform  a  task. 

6. 6.7.1. 14  Process  Management  Window 

This  window  uses  pull-down  menus.  The  convention  appears  to  be  push  buttons,  but  when  selected 
act  as  pull-down  menus.  The  functionality  is  based  on  the  IBM  tool,  but  the  GUI  conventions  are 
different.  This  window  combines  four  process  management  areas  (resource  control,  job  schedule, 
subsystems,  and  accounting).  By  combining  the  four  functions,  multiple  windows  have  been  reduced 
down  to  one  window.  This  design  minimizes  real  estate  and  the  number  of  windows  that  an  operator 
must  access  to  perform  a  task. 
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6.6.7.1.15  Backup/Restore  Window,  Backing  Up  Filesystem  Window 

These  windows  use  a  combo  box  approach  (difference  in  the  look,  rectangle  versus  arrow).  The 
functionality  is  based  on  the  IBM  tool,  but  the  GUI  conventions  are  different.  The  Backup/Restore 
window  combines  two  functions,  thus  minimizing  the  number  of  windows.  This  design  approach 
minimizes  the  amount  of  typing  required  to  perform  or  select  options  for  a  particular  task  thus 
reducing  operator  error.  In  addition,  the  data  is  placed  in  a  simple  and  well-organized  manner,  which 
provides  a  simple  way  for  the  operator  to  navigate  through  the  system. 

6.6.7.1 .1 6  Shutdown/Re-boot  Window 

This  window  uses  a  combo  box,  toggle  on/off,  and  a  display  input  field.  The  functionality  is  based  on 
the  IBM  tool,  but  the  GUI  conventions  are  different.  The  combo  box  allows  the  user  to  either  select  or 
type  the  required  information.  Also  depending  on  the  selections  of  the  operator,  functions  can  be 
activated/deactivated.  This  window  includes  an  option  to  broadcast  a  message  warning  users  of  the 
shutdown/reboot.  The  message  is  to  be  displayed  in  the  alert  area  of  systems  affected.  The  display 
message  is  in  a  format  that  brings  attention  to  the  operator  (red,  flashing,  beeping,  etc.).  This  window 
combines  Shutdown  and  Re-boot  functions  which  minimizes  the  number  of  windows  required.  The 
design  also  provides  a  clear  way  of  moving  through  the  window,  which  reduces  pointer  and  eye 
movement  requirements. 

6.6.7.1.17.  GPS  System  Administration  Windows 

The  GPS  system  runs  on  a  Sun  Solaris  Platform.  At  this  time,  the  system  administrators  in  the  test 
environment  are  using  Solstice  along  with  command  line  options  to  perform  system  administration 
activities.  It  is  anticipated  that  the  system  administration  tool  is  Solstice  or  a  compatible  Sun  tool 
(GUI  conventions  are  consistent  with  Solstice). 

6.6.7.1.18.  SBIRS  System  Administration  Windows 

SBIRS  runs  on  a  Silicon  Graphics  System  Platform.  At  this  time,  it  is  anticipated  that  the  tool  for 
system  administration  is  compatible  with  the  IRIX  (operating  system  for  Silicon  Graphics)  operating 
system.  No  analysis  has  been  performed  on  the  IRIX  operating  system  or  compatible  COTS  tools. 

6. 6.7.2  Security  Administration  Windows 

Listed  below  are  the  Operations  Support  specific  functions  that  apply  to  Security  Administration. 

6.6.7.2.I.  Security  Main  Window,  C2  Audit  Window,  C2  Audit  Select  Report  Window 

These  windows  can  be  used  as  a  menu/navigation  area  for  the  key  functions.  The  functionality  for 
these  windows  is  based  on  a  combination  of  several  COTS  tools.  This  combination  uses  push  buttons 
that  provide  a  drill-down  option  to  get  to  the  required  function  and  multiple  windows.  This  design 
maximizes  the  number  of  windows,  but  information  is  presented  in  a  simple  and  in  a  well-organized 
manner.  Because  data  is  organized  in  an  orderly  and  clutter-free  grouping,  user  performance  is 
expected  to  improve. 
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6. 6. 7.2. 2.  User  Specific  Report  Selection  Window 

This  window  uses  a  scrollable  list  box,  combo  box,  and  push  buttons.  The  functionality  and  GUI 
conventions  are  based  on  several  COTS  tools.  The  scrollable  lists  provide  the  option  of  having  all 
data  accessible  on  one  window.  The  combo  boxes  minimize  typing  requirements  and  provide 
selectable  options.  This  design  provides  clear  indication  of  inter-relationships,  which  reduces  the 
number  of  actions  that  an  operator  must  perform  thus  minimizing  the  potential  for  operator  error. 

6.6.7.2.3.  C2  User  Report  Window 

This  window  produces  a  formatted  report  using  output  fields,  scrollable  list  boxes,  colored  text,  and 
push  buttons.  The  data  is  gathered  from  the  Audit  Log  information.  If  there  is  a  problem  area  or  failed 
status  within  the  report,  the  text  utilizes  color  status  by  turning  red  to  indicate  the  problem.  This 
design  presents  information  in  a  simple  and  well-organized  manner.  Note:  Colored  text  may  be 
difficult  to  read,  therefore,  alternative  color  status  (i.e.,  color  borders,  indicator  borders,  etc.)  coding 
methods  should  be  considered  first  if  available. 

6.6.7.2.4.  Alarm  Monitoring  Window 

This  window  uses  a  file  menu,  hierarchical  icons,  a  scrollable  list  box,  and  push  buttons.  The 
functionality  is  based  on  a  security  alarm  monitoring  COTS  tool.  The  window  is  designed  to  show 
status  in  the  window  area  while  using  the  menu  as  navigation  point.  If  an  alarm  has  occurred  for 
either  network  (firewall,  routers,  bridges)  or  server,  the  icon  buttons  are  to  have  a  red  border.  The 
detail  on/off  button  can  be  selected  for  either  area,  and  information  is  to  be  displayed  below  the 
buttons  in  the  details  area.  If  additional  information  is  required,  a  report  can  be  selected  from  the 
menu  area.  All  alarm  messages  are  also  displayed  in  the  alert  area  and  an  email  is  to  be  sent  to  the 
security  administrator.  The  status  area  allows  the  operator  to  access  data  without  having  to  open 
additional  windows.  As  a  result,  a  visual  awareness  of  alarm  status  area  is  provided.  This  design 
minimizes  real  estate  and  the  number  of  windows  that  an  operator  must  access  to  perform  a  task. 

6.6.7.2.5.  Firewall  Configuration  Window 

This  window  is  designed  with  a  push  button  and  file  menu  approach.  The  functionality  is  based  on 
firewall  COTS  tool.  The  file  menu  option  provides  fast-path  access  into  a  particular  area  that  reduces 
the  number  of  windows.  This  is  a  good  option  for  a  more  experienced  user.  The  push  button  would 
allow  a  less  experienced  user  to  step  through  the  windows.  This  design  provides  functionality  for  both 
types  of  users.  It  is  similar  to  the  Alarm  Monitoring  Window;  however,  it  does  not  provide  a  status 
area. 

6. 6.7.3.  Database  Administration  Windows 

6.6.7.3.I.  Database  Management  Main  Window,  Open/Close  Database  Change 

Request  (DBCR)  Window,  DBCR  Search  Results  Window,  DBCR  Transfer 
Window,  Database  Utilities  Window,  Move  To  Operations  Window 

The  Database  windows  were  designed  to  minimize  real  estate  by  providing  ‘pull-down  menu  arrow’ 
options,  toggle  buttons,  push  buttons,  and  input/output  fields.  This  minimizes  the  number  of  windows 
that  an  operator  must  access  to  select  a  task.  In  addition,  the  data  is  presented  in  a  simple  and  well- 
organized  manner  minimizing  pointer  and  eye  movement  requirements. 
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6. 6. 7.3. 2.  GPS  Database  Windows 


From  initial  investigation,  it  has  been  determined  that  GPS  plans  to  use  Oracle  as  the  COTS  database. 
It  has  not  been  determined  if  a  front  end  GUI  needs  to  be  built  to  access  the  COTS  database. 

6.6.7.3.3.  SBIRS  Database  Windows 

From  initial  investigation,  it  has  been  determined  that  SBIRS  plans  to  use  Sybase  as  the  COTS 
database.  It  has  not  been  determined  if  a  front  end  GUI  needs  to  be  built  to  access  the  COTS  database. 

6.6.7.4.  Training/Simulation  Windows 

6.6.7.4.1.  Training:  Run/Control  Simulation,  Plan  Simulation,  Playback  Simulation, 
Update  Student  Database  Window 

The  Training  windows  were  designed  to  minimize  real  estate  by  providing  tabbed  pages.  This  GUI 
technique  minimizes  the  number  of  windows  that  an  operator  must  access  to  perform  a  task, 
maximizes  reuse  and  efficiency  of  windows,  minimizes  operator  actions,  and  presents  information  in 
a  simple  and  well-organized  manner. 

6.6.7.4.2.  Import/Edit  Script  Window,  Save  Script  Window,  Save  Initial  Conditions 
Window,  Save  Sim  Window 

These  windows  were  designed  to  use  or  be  consistent  with  the  standard  import/save  window.  Data  is 
placed  in  a  simple  and  well-organized  manner,  which  minimizes  operator  error. 

6. 6.7.4. 3.  Initial  Condition  Window 

This  window  contains  the  ability  to  set  the  initial  conditions  of  the  satellite  before  a  simulation 
begins.  The  GUI  techniques  used  include  push  buttons,  option  menus,  scrollable  lists,  and  combo 
boxes.  This  design  provides  a  clear  indication  of  interrelationships,  which  reduces  the  number  of 
actions  that  an  operator  must  perform. 

6. 6.7.4. 4.  Insert  Anomaly  Window 

This  window  contains  the  ability  to  insert  an  anomaly  real-time  during  a  simulation  by  using  combo 
boxes  and  push  buttons.  This  design  provides  a  clear  indication  of  interrelationships,  which  reduces 
the  number  of  actions  that  an  operator  must  perform. 

6. 6.7.4. 5.  Abort  Window,  Delete  Student  Record  Window 

These  windows  act  as  warnings  by  providing  messages  to  confirm  selected  actions  prior  to  execution. 
The  design  uses  the  standard  Motif  ‘warning’  type  window  conventions. 

6.6.7.4.6.  Student  Record  Window 

This  window  contains  the  ability  to  create  or  edit  a  student’ s  simulation  record  by  using  combo  boxes, 
toggle  buttons,  input  fields,  and  push  buttons.  This  design  minimizes  real  estate  and  the  number  of 
windows  that  an  operator  must  access  to  perform  a  task. 
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6.6.7.4.7.  GPS  Training  Windows 

The  GPS  program  has  designed  and  developed  a  high  fidelity  GUI  training/Simulator.  The  GPS 
simulator  uses  some  of  the  following  GUI  techniques:  push  buttons,  scrollable  lists,  input/output 
fields,  toggle  buttons,  and  drag  and  drop.  Based  on  initial  investigation,  it  appears  as  if  the 
functionality  for  the  GPS  simulator  is  similar  (with  added  options/function)  to  the  windows  designed. 
In  addition,  the  conventions  used  in  developing  the  GUI  appear  to  be  consistent  with  the  conventions 
presented  in  this  document 

6.6.7.4.8.  SBIRS  Training  Windows 

The  SBIRS  program  is  using  a  Lockheed  Martin  Mission  Systems  (LMMS)  software  developed  tool 
called  Basic  Outboard  Software  Simulator  (BOSS)  to  do  basic  simulation/training.  The  BOSS 
program  provides  command  responses  while  generating  telemetry.  To  accommodate  additional 
training/simulation  requirements  for  SBIRS,  it  is  anticipated  that  a  GUI  set  of  windows  needs  to  be 
designed/developed  to  run  with  BOSS  and/or  BOSS  enhancements.  However,  at  this  time  those 
interfaces  have  not  been  developed. 
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Appendix  A  -  Definitions 


ACCELERATOR  KEY  -  Consists  of  a  modifier  key  (<Shift>,  <Alt>,  or  <Ctrl>)  and  one  other  key. 
This  is  used  by  experienced  users  for  quick  and  consistent  access  to  certain  functions  or  actions. 

ALARM  -  The  most  critical  alert  category.  Indicates  that  a  condition  exists  which  requires 
immediate  operator  action. 

ALERT  -  Indication  of  a  condition  regarding  people,  systems,  or  the  mission,  categorized  into  alarms, 
warnings,  events,  and  informational  messages.  Alarms,  warnings,  and  events  must  be  explicitly 
acknowledged.  Informational  messages  do  not  require  acknowledgment. 

DRILL  DOWN  -  Method  of  invoking  (gaining  access  to)  another  window  that  provides  more 
detailed  information  on  the  component  or  icon  selected. 

EVENT  -  An  alert  that  notifies  the  operator  of  conditions  which  require  explicit 
acknowledgment,  but  does  not  have  the  criticality  of  a  warning  or  an  alarm. 

EXPLICIT  FOCUS  -  A  keyboard  focus  model  that  sends  keyboard  actions  to  the  window  or 
component  that  was  specifically  selected  by  a  mouse  button  or  keyboard  event. 

FIELD  -  A  rectangular  construct,  wider  than  high,  that  appears  sunken  (light  colored  border 
[(edge)]  on  bottom  and  right  side  with  dark  color  [(dark  gray)]  on  top  and  left  side).  An  area  where 
output  data  is  displayed  or  input  data  is  entered. 

ICONIFY  -  To  collapse  a  window  into  an  icon  representation  of  the  window.  This  is  distinct  from 
minimizing  a  window. 

IMPLICIT  FOCUS  -  A  keyboard  focus  model  that  sends  keyboard  actions  to  the  window  or 
component  that  the  mouse  pointer  is  over  (no  explicit  selection  action  is  needed). 

MESSAGE  -  An  informational  notice  which  does  not  require  acknowledgment  by  the  user. 

MINIMIZE  -  Procedure  to  make  a  window  as  small  as  it  can  be  without  being  closed  while  still 
displaying  some  or  all  of  its  contents  meaningfully.  This  is  distinct  from  collapsing  or  iconifying  a 
window. 

MNEMONIC  -  Identified  by  underlining  a  single  character  and  normally  used  in  menu  titles  and 
menu  options.  When  the  construct  (menu  or  other)  has  input,  focus  keyboard  entry  of  the 
mnemonic  executes  the  selection. 

ON-LINE  SYSTEM  -  A  system  that  is  currently  active. 

OFF-LINE  SYSTEM  -  An  inactive  system,  typically  a  redundant  backup  system. 

WARNING  -  An  alert  that  indicates  a  condition  that  may  escalate  to  alarm  criticality.  This 
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requires  operator  acknowledgment. 

WORK  ZONE  -  The  area  not  used  by  the  header,  the  screen  control/toolbar,  and  the  status  zone  alert 
areas.  The  area  is  used  for  placement  of  application/domain  windows  to  support  the  tasks  described  in 
the  Functional  Task  Analysis  (FTA)  (Fockheed  Martin  Mission  Systems,  1998). 


Appendix  B  -  Acronyms 


AFSCN 

Air  Force  Satellite  Control  Network 

AIAA 

American  Institute  of  Aeronautics  and  Astronautics 

AIX 

Advanced  Interactive  Executive 

ANSI 

American  National  Standards  Institute 

ARTS 

Automated  Remote  Tracking  Station 

ASTRO 

Automated  Scheduling  Tools  for  Range  Operations 

BOSS 

Basic  Outboard  Software  Simulator 

C2 

A  level  of  DoD  security 

COTS 

Commercial  Off  The  Shelf 

CPU 

Central  Processing  Unit 

DBCR 

Database  Change  Request 

DEC 

Digital  Equipment  Corporation 

DII 

Defense  Information  Infrastructure 

DoD 

Department  of  Defense 

DSCS 

Defense  Satellite  Communications  System 

DSIS 

Defense  Communications  System/Satellite  Control  Facility  Interface  System 

DSP 

Defense  Support  Program 

FEP 

Front  End  Processor 

FT  A 

Functional  Task  Analysis  of  the  Air  Force  Satellite  Control  Network  Satellite 
Control  Operations  (Lockheed  Martin  Mission  Systems,  1998) 

GOTS 

Government  Off  The  Shelf 

GPS 

Global  Positioning  System 

GUI 

Graphical  User  Interface 

HCI 

Human  Computer  Interface 

HCISSO 

Human  Computer  Interface  for  Satellite  System  Operations 

HMI 

Human  Machine  Interface 

HP 

Hewlett  Packard 

HP  UX 

Hewlett  Packard’s  Unix  operating  system 

IBM 

International  Business  Machines 

IRIX 

Operating  system  for  Silicon  Graphics 

IRO 

Inter-Range  Operations 

IRON 

Inter-Range  Operations  Number 

JTA 

Joint  Technical  Architecture 

LMMS 

Lockheed  Martin  Mission  Systems 

MCC 

Mission  Control  Complex 

MS 

Microsoft 

MUE 

Mission  Unique  Equipment 

OOH 

Orbital  Operations  Handbook 

OPSCAP 

Operational  Capability 

OSF 

Open  Software  Foundation  -  produced  OSF/Motif  Style  Guide  Rel.  1.2 
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RGF 

Remote  Ground  Facility 

RFI 

Radio  Frequency  Interference 

RSC 

Research,  Development,  Test  &  Evaluation  (RDT&E)  Support  Complex 

RTS 

Remote  Tracking  Station 

SB  IRS 

Space  Based  Infrared  System 

SOC 

Satellite  Operations  Center/Complex 

SSP 

Satellite  Support  Plan 

STK 

Satellite  Tool  Kit 

SV 

Space  Vehicle 

TAFIM 

Technical  Architecture  for  Information  Management 

US 

United  States 
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